hi
i'm going to be responsible for deciding how tagging branching is going to happen in our CVS/SVN repo.
Is there any literature that will help me understand the best way to work with CVS? either branching/tagging, etc?
thanks
For what to do, not necessarily how to do it.
David Thornley
2009-01-21 15:45:51
+16
A:
My personal experience during more than 10 years of CVS at the FreeBSD project is: switch to something else as fast as you can. CVS is file oriented not snapshot/changeset oriented which makes merging beween branches rather painful. Branches are painful with CVS anyway.
As for resources for CVS see CVS Home
If you want to talk about SVN, I'd suggest the SVN Book itself and this question.
Keltia
2009-01-21 15:08:07
I only used CVS for a couple of years, but I quicky formed the same opinion. When starting from scratch we used SVN and found it, while not perfect, still vastly preferable.
Marcus Downing
2009-01-21 15:48:05
The biggest problem I have with CVS is that commits aren't guaranteed to be atomic. Much hilarity ensues. Just use a modern VCS... SVN is pretty good for most purposes.
rmeador
2009-01-21 15:49:22
Commits in CVS are "atomic" in the same directory (due to locking) but not outside. Recent versions (1.12) have a commit id stored in the RCS file but it is still a hack.
Keltia
2009-01-21 17:56:20
+5
A:
Sensible rules of thumb:
- Tag every build (ie., every build with a build number--anything you might send to testers or anyone else).
- Branch every time you need to branch.
Usually you need to branch released versions so you can test and release patches. You might have other reasons for branching.
And you're definitely better off with Subversion.
Darcy Casselman
2009-01-21 15:08:55
"Tag every build" should be "Tag every release"? At best every commit builds but a tag for every revision doesn't make much sense..
0xA3
2009-01-21 15:10:55
I think it's better to say: tag every public build. Build that goes away from developers, for testers or users, etc.
abatishchev
2009-01-21 15:10:55
I don't see the need to be stingy, but if you're going to be, "every public build" is probably okay.If something goes wrong from one build to the next, it's easier to roll back if you'd tagged the last build.
Darcy Casselman
2009-01-21 15:20:21
You don't need to tag every build, simply because every revision is already a tag with the revision number as name (see http://svnbook.red-bean.com/en/1.1/ch04s06.html)
0xA3
2009-01-21 15:44:02
What do you mean by "every build"? If I'm doing it right, each revision number is a build. I can see tagging every build that escapes development (which currently includes some of the nightlies where I work), but aside from that I wonder whether we're using "build" the same way.
David Thornley
2009-01-21 15:44:48
In CVS revision numbers are not tags, there is no relation between different files.
David Sykes
2009-01-23 14:22:12
Okay, yeah, if you're doing the proper continuous integration thing, then every commit is a build and you probably don't need to tag every one of those. You should tag every build that goes out to your testers or elsewhere. Anything you'd assign a build number to.
Darcy Casselman
2009-01-23 19:09:25
+4
A:
I recommend you SVN on Windows, Git on Linux. Don't use CVS, imho it's terrible.
SVN Book is that what you need first.
Tag every public build (release). Branch is a copying out trunk for some reason - e.g. another way of development. Branch repository everytime when you need :)
abatishchev
2009-01-21 15:14:22
+5
A:
I'd recommend reading the two Pragmatic Programmer books on SVN and CVS called "Pragmatic Version Control Using CVS" and "Pragmatic Version Control Using Subversion".
Both are excellent resources full of recipes describing what you want to do rather than the nuts and bolts descriptions of technology itself in the books previously mentioned.
HTH
cheers,
Rob
Rob Wells
2009-01-21 15:22:14
+3
A:
The later entries in Eric Sink's Source Control HOWTO cover branching and merging.
Bill the Lizard
2009-01-21 15:43:58
+1
A:
you should leave CVS. CVS is old and not very fast in terms of branching/tagging(branch/tag creation depends linearly on number of files in a project)
You should think of your branching strategy first: do you want to have a
- stable trunk
- feature branches
- developer branches
- unstable trunk / release branches
- platform branches
This heavily depends on your project and development philosophy
If you want to use SVN you really have to think of your repository layout, because nearly all softwareprojects are module-based and you should find a structure in which you can easily tag all needed modules. SVN with its folderbased approach of branches/tags is not easy to achieve this requirement.
This said it should be clear, that multirepository layouts are more difficult to maintain a stable tagging system. I prefer a "tag all" approach, however this is my personal choice.
Peter Parker
2009-01-21 18:16:28
> This said it should be clear, that multirepository layouts are more difficult to maintain a stable tagging system.Without knowing exactly what you mean, I wonder if this can be remedied by the use of svn:externals to pull the multi-repository layout together prior to tagging.
RjOllos
2009-09-10 23:27:11
you can do this by using externals, however things will get nasty, if your subprojects are using externals themselves. There is no way of searching for all externals in all projects and it is PiA to maintain externals in more than one level..
Peter Parker
2009-09-11 21:44:04
+1
A:
I'd recommend using GIT as the tagging/branching process is extremely easy to use. The benefit of using SVN (especially on windows) is the number of GUI tools and the windows shell intergration.
I also second the recommendation for the Pragmatic Programmer books on SVN.
mwahab
2009-01-21 18:18:57
+3
A:
I believe this is from coding horror:
Chris Birmele's paper on Branching and Merging is the best introduction I've found to this essential source control task. There are dozens of ways to branch, and no one correct way to do it. Get familar with your options so you know what the tradeoffs are with each one.
Jim T
2009-01-22 14:05:32
+2
A:
If you want a starter for 10 for subversion:
Treat 'trunk' as a complete history of your development. Everything that ever gets released must appear in trunk at some point and in some form.
Use development branches(branches from trunk) in complicated development tasks. When task is finished, use re-integrate merge to pull changes from the branch into trunk. This way you have a few specific commits to trunk instead of many commits all related to the same task. Delete these development branches when no-longer needed. Name them like 'FeatureX'
Use version branches(again from trunk) to manage marketing versions which are destined to get released to customers/deployed to live. A version is a subset of the revisions in trunk. To use them, branch from trunk at an appropriate revision (may not be head), manually record the revisions from trunk as being merged into that branch, merge in any additional revisions you need from trunk (only from trunk). Do not develop directly onto a version branch, only merge from trunk - although the merge may need extra work to make it compatible with the version. Name like 'Version 2.4'
Create specific tags from your version branches whenever you make a build or hotfix that gets released to customers or deployed into live. Name like '2.4.1', '2.4.2' etc.
Working this way you can use subversion's merge-tracking (version 1.5 and above) to see exactly what's in each tag in a revision by revision basis. To do this, get a working copy of your tag or version branch and do 'svn mergeinfo --show-revs merged http://svn/trunk c:\workingcopy\'
That's great for auditors, auto-generated release notes, testers, and your own confidence about exactly what's in and what's out. Use an auto-generated matrix with this information to see at a glance what different versions contain.
Jim T
2009-01-22 14:26:23
You say that all changes should go into trunk first, and never to develop directly into a version branch. I agree, but what about fixing bugs in a version branch, whose code is no longer available in trunk (perhaps due to code cleanup or feature removal)?
morbaq
2010-03-08 14:26:41
+2
A:
When going to my first real SCM (from source safe) years ago, I found the following helpful - back then there was a white paper by perforce I think:
Tim
2009-01-22 14:50:00