A while back, I posted an entry about using Subversion and just got a comment on it a day or two ago with a question about tags. Tags are absolutely essential in CVS, but in Subversion, they're a bit less required. Still very useful, however.
In a nutshell, a tag is a named handle on a given set of files at a given set of revisions. A tag lets you, at any future time, extract that set of files in one fell swoop. The typical scenario is doing releases. When you get ready for a release, you create a tag for the source that is being released. Then if you ever need to look at the source for that release again, you can easily pull it back out.
With Subversion (unlike CVS), there isn't a difference between a tag and a branch. A tag is simply a branch that has never been committed to. A very typical use case is to create a tag when you do a release, and then when you need to make a fix to that release (independant of the main trunk of development), you create a branch at the release tag. You make your fixes on that branch, and then merge them back into the trunk for inclusion in future releases of the product.
In my previous post, I'd alluded to using a tag and an externals definition together to ensure that inter-project dependancies were managed via Subversion rather than manually. In that particular case, you create a tag on the dependancy for the version you want to use, and then set up an svn:externals definition in the parent project that points at the tag. Then everyone that checks out the parent project will be assured of having the same version of the project's dependancies. Even better, changing the location of the tag in the future will automatically update everyone's working copies next time then run svn update, which makes dependancy upgrades a snap.
And keep in mind, Subversion can handle binary files as well as text files, so I'd highly recommnd storing EVERYTHING in your repository, be it your development tools (Eclipse), external libraries (any JARs or DLLs your app might need), server configuration files (web server, DB server), bootstrap scripts, etc. Aside from hardware and system software, creating a new environment to run your application shouldn't require anything that's not stored in version control.
Interesting – I'm moving more and more stuff into SVN but never thought to actually move my applications (CFEclipse) themselves into it…
I've seen huge messes created when non source files are checked into cvs/svn etc… I've even see old log files checked in.
Source control is for source code. Dependencies can and should be kept in some type of repository (like Artifactory). Deployment tools (maven or ant) put your source code and your deps together to create the application. Keep your source in svn. Keep everything else out of svn.
yoyar,
How is Artifactory different from SVN/CVS? They're both just repositories that store stuff and keep track of the evolution of that stuff across time.
I agree with yoyar.
Although it is nice to have all the stuff checked in, but some of them just bloat the repository and do not really belong there. I've seen people check in a CD image that contained something for a presentation they wanted to hold. Then they deleted it again but did not realize that the trick of version control is that it is still present, just not visible in the latest revision.
As a general rule I would say: What can't be generated from what's under version control should be checked in if it is necessary for the program to run. But I wouldn't check in an exe file just because it will change with every time it is compiled. If a compiled program has to be kept for reference/memory/sentimental reasons, then I would not version the file that is produced by the compiler but rather a file which I copy to a place manually or per script only at times when I would like a new version to be stored.
Updating binary files over and over will only increase the size of the repository. CD images should (in all cases that I could think of at the moment) not be checked in because it is hard to get them out (export/import + filter).
Maybe your EVERYTHING meant just what we said. Checking in everything selfmade is really useful, I agree. When using an IDE, I would like to be able to go back to a revision and open the stuff in my IDE to compile it. I don't want to create a new project and add the source files which I versioned there. But not more than the stuff I need. No log files, no compiled exe files that are the results of my source.
Regards,
BiGF00T
Storing development tools in SVN is one of the stupidest ideas I have ever heard. That can work only if the SVN is used by one user. Let's see the following scenarios:
1/ One user on windows, one on linux. Both are using java sources but can't share eclipse binaries.
2/ One user on SVN, has to buy a new computer, different OS, old eclipse on SVN (or other app) won't work (e.g. because old computer was 32bit and the new one is 64bit)
3/ system paths can be different, even localized on windows. Some applications need values in system registry. You can commit your application files to SVN but when you need to checkout to a new computer, the tools won't work.
In general, you should commit to your SVN only your own work. Not any external tools that are available from other SVNs or websites. It's better to create a script that will download and install them all and put that script to your SVN (or maybe download some of the binaries to your FTP).
I was looking for step by step instructions on how to create a tag in SVN. This topic seemed to suggest it would do that – but I am still mistified.
Barrie,
You just need to do `svn mv /path/to/src /path/to/tag` and that's it. The tag path must be a server URL, but the source path can either be a working copy or a server URL.
I did eventually work it out. For anyone else that is interested:
1: Open the Repo Browser
2: Find the trunk of your project
3: Right click and select Copy
4: Enter the path to where you want the copy – it should be under tags
eg: Repository\Projects\MyProject\trunk
Copy this to Repository\Projects\MyProject\tags\Releasexxx
That was it.