>
> 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
Received on Wed Jul 4 00:31:55 2007