.dproj files are essential for Delphi projects, so they have to be under version control.
These files are controlled by the IDE and also contain some information that is frequently changed, but totally irrelevant for version control.
For example: I change the start parameters of the application frequently (several times a day), but don't want to accidently commit the project file if only the part dealing with the start parameters has changed.
So how to deal with this situation?
A clean solution would be to take the file apart, but that isn't possible with the Delphi IDE AFAIK.
Can you ignore a specific part of a file?
We're using Subversion at the moment, but may migrate to Git soon.
In our case, it's rare for a developer to make a meaningful change to the .bdsproj, .dpr, .res files. So we reject the commit (pre-commit hook in subversion) unless special tags: [add project file] or [add res file] are present in the commit comment. This prevents "frivilous" changes to those files.
SVN/git cannot "know" which bits of the file are important, and translating what is important for you to commit or not into file "bits" would be difficult (especially when you don't know exactly how the information is structured within it). The most practical solution is to check the changes that have been made to the file and decide whether to commit them or not to the repository.
You can decide which bits of the file you want to commit with git. This is not, however, the automated process you seem to be looking for.
For the specific case of startparameters: the DDevExtentions plugin of the well known Andreas Hausladen allow for the start parameters be stored separetely of dproj file. See more details about DDevExtensions on his site.
EDIT: If I remember correctly, this feature was created just because he had that exact problem with start parameters and version control.
I would not save the .dproj files directly in version control, but rather provide a default file which should be renamed by the user to get the flawed Delphi working.
Use the --assume-unchanged option on git update-index <file> as described here and stackoverflow/what-is-assume-unchanged.
You could make simple aliases for the those who need it made simple.
Related
So in a typical workflow of a developer, it goes something like this:
You sync your workspace to some changeset, do some work, shelve changes you've made.
My question is, internally, when you create a shelveset, does TFS keep track of which changeset the changes are based on? If so, is there a way to look this up?
My rudimentary understanding is that, yes, this changeset information must be somehow recorded because shelvesets are stored internally as delta's, as opposed to full copies of files and without a record of which changeset the delta is based on, a delta is basically useless.
That may be a typical workflow for your team, but I'd say that it's not a typical workflow in general.
Shelvesets are intended for short-term suspension of work in progress that's not quite ready to be committed to a dev branch, generally in the case of something exceptional occurring that requires immediately switching contexts (e.g. troubleshooting or fixing a bug).
Internally, TFS actually stores most files as reverse deltas. Why? Probably because the most frequently accessed state of a file is the current version, and having to "build" the current version by playing forward a series of changes to the originally file is going to be a lot more expensive. Basically, when you go to look at an old version of a file, it takes the current version of the file and "peels off" the intervening changes until it's back at the old version.
Your specific question is actually directly addressed:
Shelvesets also use the same mechanism for storing their content. However, with shelvesets, no deltafication happens. Each shelveset gets a new copy of its file(s). (except in the case of a merge). When a shelveset is checked-in, a shallow copy occurs and the committed version of a file uses the same content as the shelveset copy of the file referenced. Deltafication will be started on the previous version of the file(s).
So, long story short, shelvesets are not based on changesets.
I concur with Daniel's answer that the files of a Shelveset are copies of new files. However, I'm not sure when this was incorporated but currently in VS2017 the Changeset is actually stored. When looking at the Shelveset Details if you hover your curser over a file among the details displayed for the file is the "Version" it is based off of.
Example Image
I don't know how useful this will be for the typical user as I have found one of the best features of Shelvesets is the modularity and separation from the version control but it never hurts to have that context.
Cheers!
I've got a VS/TFS2010 project in which we use a generated file. Here's how it works:
There's a pre-build event that creates the file (foo.cs)
The file is included in the project.
The file is NEVER added to TFS version control.
It works great, except... People have an unfortunate habit of accidentally checking in the file. This, of course, breaks the system.
Are there any good ways to prevent this from happening? Can I at least set up some kind of watch mechanism to alert me if it does happen?
You'll need to install the Team Foundation Server Power Tools, which will include the "Forbidden Patterns" check-in policy. This will allow you to prohibit a file from being checked in based on regular expression applied to the server path.
This will allow you to simply add the full server path of the file you wish to ensure does not get added. For example:
^\$/TeamProject/Folder/foo\.cs$
I was researching this exact issue today and found this, which may be of some help: How to ignore files/directories in TFS for avoiding them to go to central source repository?
Not sure if 2010 has made this easier or not.
(Apologies, this should probably be a comment, but I don't think I have enough rep to comment.)
I like to backup up the source code set for a project when I release a version. I use GExperts project backups, which seems to gather up all the files in the project manager into the ZIP file. You can also add arbitrary files to this file set, but I'm always conscious of the fact that I haven't necessarily got all the files. Unless I specifically go though the uses clauses and add all the units I have sources for to the project, I'll never be sure of storing all the files necessary to recreate the installable/executable.
I've thought about rolling an app to traverse a project, following all the units used and looking down all the search paths and seeing if there is a source file available for that unit, and building a list of files to back up that way, but hey - maybe someone has already done the work?
You should (highly recommend) look into Version Control.
e.g. SVN (subversion), CVS
This will allow you to control revisions of all of your source. It will allow you to add or remove source files, roll back merge and all other nice things related to managing project sources.
This WILL save your a$%# one day.
You can interpret your question in two ways:
How can I make sure that I backup at least enough files so I can build the project
How can I make sure that I backup not too many files so I can still build the project
The first is to make sure you can build the system at all, the second to allow you to clean up unused files.
For both, a version control system including a separate build system is the way to go.
You then - for each new set of changes - can use these steps to assure that both conditions hold:
On your daily development system, check in the new revision of your source code into your version control system.
On your separate build system, get the latest version of your source control system.
Build the project on the build system; if this fails, go to Step 1, and add the missing files to your version control system from your development system
Start removing (one-by-one) files from the project that you suspect are not needed, then rebuild until it fails.
When the build fails, restore that particular file from the version control system, then continue step 3 with the next candidate
When the build succeed you have the minimum set of files.
Now make a difference overview of the files in your version control system, and the build machine.
Mark the files that are in your version control system but not on your build machine as deprecated or deleted.
Most version control systems have good ways of generating a difference between the files on your development or build system against the files in the version control system (usually fine grained for each historic point in time you added/removed/updated files in your version control system).
The reason you want a separate build system (or two separate development systems) is that you want them to be independent: you use one for developing, and the other for checking if the build is still OK.
This is the first step that in the future you might want to extend this into a continuous integration system (that runs unit tests, automatically creates product setups and much more).
--jeroen
I'm not sure if you're asking about version control or how to be sure you've got all the files.
One useful utility I run occasionally is a program that makes a DirList of all of the files in my dcu output folder. Changing the extensions from .dcu to .pas gives me a list of all of the source code files.
Of course it misses .inc files and other non-.pas files, but perhaps this line of thinking would be helpful to you in some way?
The value of this utility to me is that a second housekeeping utility program then makes a list of all .pas files in my source tree that do not have corresponding .dcu files. This (after a full compile of all programs) generally reveals some "junk" .pas files that are no longer in use.
For getting a list of all units compiled into an executable, you could let the compiler generate a MAP file. This file will contain entries for all the units used.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I desperately need source control to manage projects between more than one developer.
A long time ago I used Visual Source Safe and it worked quite well.
What free substitutes can be recommended? I have the following basic requirements:
I need to host the repository on my own server.
I do not want extra clutter within my source files, like CVS does.
I need proper check in / check out, so that nobody can change a module until I've checked it back in.
I don't want / need source code merging / branching.
We use Delphi for web development, so many HTML files, images, SQL files, etc.
Any recommendations?
Git or Mercurial.
both are distributed and fast (each repository can act as 'server')
no extra clutter just one .git or .hg directory
you can pull changes from trusted or verified sources
I'll always recommend subversion with Visual SVN for server software and Tortoise SVN for the clients. You can exclusively check out files, so that nobody else can edit them, although that's not the default behavior. The only "clutter" it adds is a hidden .svn folder in every directory that is under version control.
If you insist on zero-clutter, and also free, you have limited choices. If you are open source, you can have a free copy of perforce. No clutter. SVN has clutter like CVS: a .something directory in each directory. git and hg just have one directory of clutter per clone.
If you absolutely insist on a checkout model, you have to give something up. P4 will do it, but none of the others will very well. Most people are more concerned these days with allowing disconnected operation than with a concept of locking. even svn lock only prevents checkin, not starting to modify.
There are other more obscure systems out there (e.g. arch) that you might look into.
I discourage the checkout/checkin approach. A decent version control system should be able to merge changes. This provides you with plenty of choices: CVS, SVN and Git.
As for "clutter" in your source files: I don't consider repository directories (e.g. .svn or .git) clutter, as this allows you to copy the repository structure.
Nevertheless, in SVN (not sure about Git) you can lock/unlock a file, basically mimicking the VSS checkout/checkin.
You should read a bit and learn a bit before you consign yourself and your fellow developers to living in the dark-ages of version control.
Visual Source Safe and the locking model of version control are dead. Most people have moved on. Those that have not are usually afraid of (or loathe) the idea of branching, and merging. Once they see that branching and merging can be easier, and more effective, then they can move onwards and upwards into a new world of version control options.
Ask yourself a few of these questions:
Would I like to separate the act of creating a new feature from the act of inflicting it on other developers, and on the final product (my live website)? If so, then I need branches. One branch = No effective version control.
Have I asked the other developers who will be working with me, what practices they find effective in multi-developer projects, and do they agree with me that locks are the way to go, or am I unilaterally enforcing my way of working with them? (You can have foo.pas for today, but try to get it checked in by 3 pm because I need to make a change to method bar inside foo.pas, later today.)
If I state that I want to make sure developers "avoid using old versions" do I have reasons for that other than that I hate or fear merging? Can we not think of any ways to prevent "using old versions"? Also, can we not think of any reasons when using old versions might be exactly what you have to do? If you used a non-locking tool like Subversion, why not say "please update before you commit". Then you will never have to merge, but if someone wishes to work with a non-changing version of the sources while developing the feature and then wishes to do the merging themselves, and you never have to merge yourself, you could insist that your work be done with locking (using subversion) but allow others the freedom to use a workflow that solves their problems, instead of yours.
Suppose (as you said in comments above) someone is removing something that you are in the act of creating. Wouldn't it be nice to see a complete list of his changes and say "I would like those changes gone, without removing other changes made by other people". This is known as working with "changesets" and is a key feature of DVCS like Mercurial (hg) and Git. In fact, the ability to prevent other people from modifying YOUR local repository willy-nilly, but rather making changes, which you can then review, and either accept or not accept will always be better at creating coherence on your (master) copy of the repository than any localized, centralized locking model can ever be.
W
You might like to investigate Team Coherence (http://www.teamcoherence.com). It doesn't create special folders and has a Delphi bent to it. For example, it groups .pas and .dfm files together by default. Help is excellent. It's also now free for a single license. I've been using it for years after previously using CVS and FreeVCS.
SourceGear's Vault is free for 1 user, and it gives you checkin/checkout plus merge-style operations. It also works totally clutter-free. I have been using it for some time and it works wonders. Transition from SourceSafe is especially easy, and integration with IDEs such as Visual Studio or Eclipse is very good.
Hmm, define "clutter" - to my mind a hidden directory per folder isn't clutter, frankly it hasn't been an issue at all (for reference, 7 years of first CVS then Subversion and prior to that VSS and something distributed the name of which eludes me).
Subversion is excellent and installation is almost trivial with VisualSVN server and use is straightforward with Tortoise as a client. Locking of files is an option, not a good one in the general instance but its there for binary files if you need it. This is probably the closest match to your criteria and I like it. A lot.
For personal use I'm playing with Mercurial - but not done enough to say more than that it works (and of course like most DVCS it fails your "lock" criteria). DVCS is different and has some issues.
If you have money, Vault (http://www.sourcegear.com) is worth a look - especially if you used and liked VSS since it started out as a "better" VSS though it has evolved somewhat. Worth visiting sourcegear just to read Erik Sink's thoughts on version control.
As for the rest, whilst I'm sympathetic to a wish not to (have to) merge stuff, writing off tagging and branching is pretty much the same as saying "I don't need version control" - it turns out not to be the case.
No one is recommending Bazaar, so here I am, I use it in my everyday work with Delphi projects.
It has a diff viewer that rocks, and that, for me at least, makes the difference with the other svn-like repositories.
I haven't used it for many years but I believe Jedi VCS meets all your criteria with the added bonus that it's written in Delphi and has some built-in smarts when it comes to handling dfm files.
We are using Fossil for source code managment of our Delphi programs.
It's very easy to use (if you like the KISS command line approach), and there is an internal web-based interface.
There is no installation needed, since it's only one executable to run. It's perfectly cross-platform: you can have your own repository on your Windows machine, then clone/synchronize it into any other server, running on Windows or Linux.
You can see our repository of Open Source Delphi programs hosted by Fossil on our web site. For internal work, I've found out that Fossil uses little bandwidth (much less than CVS or SVN), and is able to synchronize huge projects in a blitz, even via an ADSL or a 3G connection.
Here are some unique features, included in Fossil (with no third-party component to setup):
Bug Tracking And Wiki
Web Interface
Autosync
Self-Contained
Simple Networking - Fossil uses plain old HTTP
CGI Enabled - No server is required to use fossil.
Robust & Reliable
I would recommend Plastic SCM: http://www.plasticscm.com/
the best (?) merging and branching support!
but you can also use single branch + exclusive checkout (aka lock)
very nice and handy GUI
free up to 15 users
very good support (within a day, mostly within an hour!)
very modern, automatic merging and branching, distributed, etc
Delphi plugin available: http://code.google.com/p/plastic4delphi/
I'm looking for an editor that lets me see all the changes I've made to a file on a line-by-line basis.
Eclipse does this. It maintains a "local history" of every revision based on file-saves. Has saved my a** more than a few times.
Eclipse has a local history that gets updated every time you save a file. You can open a change log for the file and compare it to previous versions. It can also recover deleted files.
Apple's Xcode 3.x has a Project Snapshot feature that snapshots all files, so that you can compare and go back later.
As for using a "real" version control system, of course, you should do that, too.
If you work in a group it is basically a must.
But that does not make local history tools provided by the editor obsolete. I see those more as a natural extension of Undo. Just like I cannot use Windows Notepad anymore because it has only one level of Undo, I am beginning to expect that editors let me undo changes that I made last week.
It is Eclipse. It also support multiple language by adding plugin. You can compare each change by comparing with local history. Only you have to take precaution, this tool won't help to revise the changes if you change the file other than eclipse editor.
You'll need some sort of version control software to keep track of all your changes, and a diff/merge tool. Most of the popular version control systems (Subversion, TFS, Source Safe, etc.) come with a builtin visual diff tool.
For example with Java, you can use Eclipse with a Subversion plugin called Subclipse.
There are also standalone diff/merge tools available. Here's a good one for Windows:Winmerge
If you like Vim, there is a builtin difftool called vimdiff. (This would be an example of an editor with diff capabilities).
I'm sure Emacs also has diff tools available, but I wouldn't know.
By using a revision control program like Subversion/CVS/Git you can use any editor and run for example "svn diff".
This is not exactly what you need but you may find it interesting.
There are no editors out there that saves revisions you made. Editors must connect to SVN in order to check their revision histories like in Zend Studio for Eclipse.