Thanks for the response. Comments below:
On Tue, Sep 1, 2009 at 2:33 AM, Bolstridge, Andrew <
andy.bolstridge_at_intergraph.com> wrote:
> Given all of your requirements, I think you do need to use SVN branches,
> however – create a branch that is the ‘development trunk’, let users commit
> to that. Then after their changes have been verified, someone else (eg a
> build manager) merges the dev trunk to the “release trunk”. This way,
> developers use their existing model – they just use a particular directory
> in SVN, and your verified designs are retrieved from the guaranteed-ok
> directory.
>
Am I correct that it would work just as well to leave developers on the main
trunk, and to create a "release branch" that is the target of periodic
merges? I suppose that doesn't get users "warmed up" to the idea of using
branches, but has the advantage of not requiring any change at all from
today's usage.
But I still don't see how this makes it easy for users to update their work
area to contain the *release *versions of all files except the ones they're
working on, which are development versions.
I'm used to the idea of tags as being user-friendly names for per-file
version numbers. So if you say "svn update -r*tagname*", you might get
version 1234 of file foo.x, but version 2341 of file bar.x. Either way,
your files are still in the same development trunk or branch they were in
before the update.
Here's an example: a user recently made the classic mistake of forgetting
to checkin one of her changes (and doing this on a Friday evening, no
less!). So people who updated their trees couldn't build. The workaround
was to grab an older version of one of the new files, to avoid dependencies
on the missing checkin. In other revision management tools I've used, one
user could manually adjust file versions to get a working tree (in this case
by grabbing an old version of that specific file), and then apply a "tag" to
all files to label these versions as good. Other users could then sync
their work areas to the tagged versions, and remain on the main development
line. I see no way to do the equivalent in SVN. Since tags are pretty much
the same as branches, which are entire parallel directories, there doesn't
seem to be a notion of "stay on the trunk, but update to a named collection
of file versions".
> The only person who has to worry is the build manager, but he will know
> what he’s doing with SVN. Once people have gotten used to this approach, you
> can start letting them have their own branches, and things will be SVN
> heaven.
>
Guess I'm not sure how well "SVN heaven" matches my own vision of "revision
management heaven" :)
> You can still ‘tag’ a revision by remembering the revision number, it’s a
> pity SVN doesn’t have support for giving these numbers a human-readable name
> (and IIRC someone submitted a patch for just that) as it would have solved a
> good deal of similar issues. The canonical svn approach is to use ‘tag’
> branches for tagging. (personally, I feel that just clutters the repository
> up, especially if you release very often).
>
I agree.
> You can update your working copy to a particular revision – just specify
> the revnum in the update command.
>
I understand that. My question is whether or not there's an easy way to
update an entire work area to a *mixed *set of versions, e.g. a one-line way
to do the equivalent of:
svn update -r1234 somedir/
svn update -r1210 somedir/weirdfile.x
svn update -r2111 otherdir/dira
svn update -r2012 otherdir/dirb
...
-Brett
--
Brett Coon - brett.coon@gmail.com - http://brettcoon.smugmug.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389855
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-01 20:13:05 CEST