On Friday 10 Feb 2006 04:31, Don Allingham wrote:
> We have an opportunity to switch from CVS to Subversion. SourceForge is
> rolling out support for subversion. From the documentation, it looks
> pretty good.
> Has anyone had any experience with it? Is it worth the switch from CVS?
I have some experience of running subversion. We migrated all of our work
systems from CVS to subversion about 2 years ago. Subversion is _much_
better. I would certainly support a move to subversion.
However, there is one thing about subversion that requires some thought before
migrating the existing code. Subversion does tagging and branching in a
completely different way to CVS. Unless you think through the layout of the
svn repository before the migration it can be a bit of a pain moving
everything around later to support the branching merging policy. This is the
thing that took the most time when we made the move.
If you intend to make the move, I can write more on the possible layout
options and how to do to the branching / tagging for our different releases.
BTE. I don't suppose sourceforge is going to allow access to the 'hook'
functions in subversion are they?
On Fri, 2006-02-10 at 07:48 +0000, Richard Taylor wrote:
> However, there is one thing about subversion that requires some thought before
> migrating the existing code. Subversion does tagging and branching in a
> completely different way to CVS. Unless you think through the layout of the
> svn repository before the migration it can be a bit of a pain moving
> everything around later to support the branching merging policy. This is the
> thing that took the most time when we made the move.
> If you intend to make the move, I can write more on the possible layout
> options and how to do to the branching / tagging for our different releases.
> BTE. I don't suppose sourceforge is going to allow access to the 'hook'
> functions in subversion are they?
If you could educate us more on the whole subversion migration issue, I
think we would all appreciate it.
On Friday 10 Feb 2006 12:49, Don Allingham wrote:
> If you could educate us more on the whole subversion migration issue, I
> think we would all appreciate it.
> More information can be found here: http://sourceforge.net/docs/E09/en/ >
> It looks like thry are offering limited hook support.
The hook scripts they are providing are not of much use to us. But never mind.
The most useful hook script would be one that added a comment to a bugzilla
issue if the issue number was included in the commit message. This is great
for tracking development, but we don't have it now so we won't miss it.
In CVS branches and tags are special attributes applied to a collection of
files and directories. The branches and tags are not apparent from the
directory structure, they are handled independently from the structure of the
repository. So roughly speaking our current CVS looks like this:
gramps/* Branches: MAIN
CVS Tags: R0_8_0,
gramps2/* Branches: MAIN, vinit
CVS Tags: R1_1_99,
Branch point for: SOUR_REPO,
manual/* Branches: MAIN
CVS Tags: HEAD
Subversion does not have the concepts of branch and tag at all. It only has
copies. However, unlike cvs, copies know where they have been copied from.
Copies are also lazy in that they don't actually make a real copy, you can
think of them as symlinks that are copied only when a change is made. This
means that making a copy in subversion is very fast, much faster than
applying a tag in cvs.
To achieve the same effect as branches and tags you have to use a
filestructure convention. For gramps this would probably look like this:
gramps2/trunk/ <-- this is the current HEAD development
2_0 <-- this is the current 2_0 branch
2_0_2 <-- these are the release tags
Note that there is nothing special about the 'trunk'. All folders are
equiverlent in their functionality, subversion does not care what you call
them 'trunk'/'branches'/'releases' are just a convention. This also means
that it is possible to checkout a releases version e.g.
gramp2/releases/2_0/2_0_1 and change it! It is only a release tag because the
conventions say it is. So you have to have some rules that say noone should
every commit changes to the /releases/ directory.
You can merge changes between any directories.
Making a release or a branch is just a copy, for example, lets imagine that we
were ready to release the current HEAD (trunk) code as release-3.0.0.