[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn vs cvs and version numbers

From: Clemens <clemens.hintze_at_thalesgroup.com>
Date: 2007-07-04 16:45:05 CEST

Tracy R Reed wrote:

(...)

> He says:
>
> The problem with using SVN at our company derives from this feature: SVN
> assigns a new version number to "the repository" for each "set" of
> changes to the repository.

Yes!

> This differs from CVS. CVS assigns a new version number to "modifed each
> file".

Hmmm he is right here too ... :-/

> Consider the following situation:

(...)

> * In CVS, we can check out version 1 of foo.php and version 2 of bar.php
> into a sandbox, tag it as RELEASE_TWO and move RELEASE_TWO into production.

No problem in SVN as well. You may compose your working copy by manually
selecting different revisions for any single file and/or dir within by
using the 'switch' subcommand of 'svn'.

Then you simply 'tag' this composition as RELEASE_TWO if you like to
preserve your work for eternity. :-)

The only "problem" that may occure is, that you cannot really 'move'
your 'tags' *after* application, as there are no 'tags' at all in SVN ;-)

> In SVN, since the versioning happens on checkins and not on files, I
> think we're screwed. I'd be happy for someone to straighten me out,
> though.

You are not, as explained above. You may use SVN without breaking your
workflow. It neither would be more difficult, nor would it be easier
than with CVS.

But perhaps you want to change your workflow to make handling easier
than before? I am sure, other readers will propose some possible
alternative to the current workflow that may fit your needs better :-)

Best regards,
Clemens.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jul 4 16:45:11 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.