svn vs cvs and version numbers

[Tracy R Reed <tr...@ultraviolet.org>]

My company is looking into converting our cvs repository to subversion. 
However, our senior developer has a concern and I'm not quite sure how 
to address the issue aside from "just use branches". Can anyone else 
provide a more eloquent answer to this?

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.

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

Consider the following situation:

* We have a web site with two files: foo.php and bar.php.
* These two files have never been modified since they were initially 
checked into the system.
* Fred makes copy edits to foo.php and commits the change.
* In CVS, foo.php has two versions: the version from the initial checkin 
(1) and the modified version (2).  bar.php has only the single version 
representing its state when it was first checked in.
* In SVN, the repository has two versions: the state when foo.php and 
bar.php were checked in (1) and the state after the changes to foo.php 
were committed.
* Now Bob makes a copy edit to bar.php and commits the change.
* In CVS, foo.php and bar.php each have two versions.
* In SVN, there is now a third revision.  The new revision (3) 
represents the state of the repository after Dan committed his changes 
to bar.php.  This includes Fred's edits to bar.php.
* The client has sent the revisions of foo.php off to its lawyers for 
review, and wants the changes to bar.php to be pushed live.  The changes 
to foo.php can't be pushed live until the lawyers approve the edit.
* 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.

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svn vs cvs and version numbers

[Talden <ta...@gmail.com>]

> 
> 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.
>
> This differs from CVS. CVS assigns a new version number to "modifed each
> file".


Quite correct. Files have 'changed in revision' knowledge rather than each
having their own revision number.
So if you change a bunch of files together they all have their latest change
at that revision number.


Consider the following situation:
>
> * We have a web site with two files: foo.php and bar.php.
> * These two files have never been modified since they were initially
> checked into the system.


Subversion:
- Both files are changed in r1 (assuming they're checked in together)
CVS:
- Both files have revision 1.1 (they will have different commit times
though)


* Fred makes copy edits to foo.php and commits the change.
> * In CVS, foo.php has two versions: the version from the initial checkin
> (1) and the modified version (2).  bar.php has only the single version
> representing its state when it was first checked in.
> * In SVN, the repository has two versions: the state when foo.php and
> bar.php were checked in (1) and the state after the changes to foo.php
> were committed.


Subversion
- foo.php is now changed in r1 and r2
CVS:
- foo.php now has revision 1.1 and 1.2


* Now Bob makes a copy edit to bar.php and commits the change.
> * In CVS, foo.php and bar.php each have two versions.
> * In SVN, there is now a third revision.  The new revision (3)
> represents the state of the repository after Dan committed his changes
> to bar.php.  This includes Fred's edits to bar.php.


Subversion
- foo.php is now changed in r1 and r2
- bar.php is now changed in r1 and r3
CVS:
- foo.php now has revision 1.1 and 1.2
- bar.php now has revision 1.1 and 1.2


* The client has sent the revisions of foo.php off to its lawyers for
> review, and wants the changes to bar.php to be pushed live.  The changes
> to foo.php can't be pushed live until the lawyers approve the edit.
> * 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.
>
> 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 screwed.  You will need to understand that the terminology
differs but that you can deliver exactly the same information as you did
before.  Content before change, Content after change.

Remember that the files can tell you which revision they were changed in not
just the current revision at the HEAD of the repository.

If we consider a somewhat more likely case for a moment.  Assume that a
client change request affects a dozen files.  Assume that, over time and due
to prior change requests, the CVS revision aren't nicely lined up (some
previous requests affected only some of the files perhaps).  That's ok, the
last changed revisions for each file are different in Subversion too.

When the developer commits the changes for change request X in CVS all of
the files get new numbers and likely they don't even have the same commit
times, unless the developer notes all of the changed files it is a task in
itself to find all of the changes.

In subversion they all get a single new number.  It is trivial to now say "I
resolved request X in r1234" - the files in that change are immediately
identifiable and their previous content can be pulled easily for comparison
or a diff can be reported directly from the revision.

Often, teams depending too much on CVS revision numbers run into its
limitations.

Do not confuse a CVS revision number for a modification count.  Any
branching and subsequent merging ruins this count (changes on the branch
won't increment the HEAD revision and the merges will). For most productive
purposes, a revision per file fails to represent a 'change' as interpreted
by a client or qa since you will often change more than a single file at a
time.

Do not confuse Subversions repository revision number with the revision
numbers in which a file/folder was changed.  Each path in Subversion knows
when it was last changed.  You can find these out with an 'ls' or an log'
command.

Don't forget that you can easily tag releases and you can compare tags.  You
can also compare a tag with the trunk at a revision to directly see the
changes.

Moving to Subversion you will need to adapt your work-flow but you don't
lose anything by moving from CVS revision numbering to a single repository
revision unless you use CVS in it's absolute most trivial form - IE never
branching and only ever doing work that applies to a single file at a time.

Moving to Subversion from CVS does have compromises, albeit a very very
short list.  The revision numbering change really isn't one of those
compromises.

--
Talden

Re: svn vs cvs and version numbers

[Ryan Schmidt <su...@ryandesign.com>]

On Jul 3, 2007, at 12:25, Tracy R Reed wrote:

> My company is looking into converting our cvs repository to  
> subversion. However, our senior developer has a concern and I'm not  
> quite sure how to address the issue aside from "just use branches".  
> Can anyone else provide a more eloquent answer to this?
>
> 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.
>
> This differs from CVS. CVS assigns a new version number to "modifed  
> each file".
>
> Consider the following situation:
>
> * We have a web site with two files: foo.php and bar.php.
> * These two files have never been modified since they were  
> initially checked into the system.
> * Fred makes copy edits to foo.php and commits the change.
> * In CVS, foo.php has two versions: the version from the initial  
> checkin (1) and the modified version (2).  bar.php has only the  
> single version representing its state when it was first checked in.
> * In SVN, the repository has two versions: the state when foo.php  
> and bar.php were checked in (1) and the state after the changes to  
> foo.php were committed.
> * Now Bob makes a copy edit to bar.php and commits the change.
> * In CVS, foo.php and bar.php each have two versions.
> * In SVN, there is now a third revision.  The new revision (3)  
> represents the state of the repository after Dan committed his  
> changes to bar.php.  This includes Fred's edits to bar.php.
> * The client has sent the revisions of foo.php off to its lawyers  
> for review, and wants the changes to bar.php to be pushed live.   
> The changes to foo.php can't be pushed live until the lawyers  
> approve the edit.
> * 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.
>
> 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're not screwed; you can certainly have a mixed-revision working  
copy. For example, to accomplish what you want, you would check out  
revision 2 of the repository (svn co -r 2 url://to/repo/trunk wcname)  
or update an existing working copy to revision 2 (svn up -r 2  
wcname), then update bar.php to revision 3 (svn up -r 3 wcname/bar.php).

It will quickly become unwieldy, however, if you have a working copy  
deployed to the live server that has individual files updated willy- 
nilly to "random" revisions. This would of course have been a problem  
with CVS too, not just now that you're using Subversion. A better  
idea is to create a branch in the repository which represents the  
state of the web site as deployed, while the trunk can continue to  
represent active development. Once a change from trunk is "approved"  
by whatever QA process you have, you can merge that change (that  
revision) into the branch. A post-commit hook can then take care of  
automatically updating the production web site to match the branch,  
if you like.

See the online book for more on these topics:

http://svnbook.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svn vs cvs and version numbers

[Les Mikesell <le...@gmail.com>]

Clemens wrote:
> 
>> * 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 ;-)

Tags aren't attributes of the files as they are in svn, but you can 
still use named directories as tags to hold groups of specific revisions 
  together.  If your work flow depends on having a specific name for a 
tag for an operation, you can emulate moving a tag by deleting the 
previous one, then copying a new workspace to that name.  The 
delete/copy operations can't be done atomically, so whatever uses the 
tag must be coordinated with the updates but since cvs did not do 
anything atomically you had to do that anyway. Since you need this 
coordination anyway you might find it easier to just use a new name for 
each tag.

-- 
   Les Mikesell
    lesmikesell@gmail.com


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svn vs cvs and version numbers

[Clemens <cl...@thalesgroup.com>]

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