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
Received on Wed Jul 4 10:26:23 2007