On Mon, Nov 20, 2006 at 03:18:43PM -0600, Les Mikesell wrote:
> On Mon, 2006-11-20 at 15:18 -0500, John Rouillard wrote:
> > >
> > > But I suspect there are things you just can't do with a tag - I just
> > > want to know what they are.
> > How about cherry pick multiple files at different revisions without
> > going crazy? See any of my prior emails/use cases on the issue.
> If you create the tag from a workspace instead of a revision
> you can tag exactly what you want.
> > The problem with SVN's tags as I see it is that it defies common
> > understandings of space/time. Space is branches - different lines of
> > development, different files in a tree etc. It is the "name" or
> > location of the object you are working on. All can be handled by a
> > url.
> > Versions/revisions always occur along the time axis not the space
> > axis. SVN even recognizes this by allowing date or revision numbers as
> > the parameter to the -r flag. SVN just doesn't follow through on it
> > preferring to use space (a tag) to define a point in time (release of
> > a portion of a tree) rather then supplying a true time only based
> > mechanism for identifying revisions of a given file or compatible
> > revisions of a set of files.
> But, there is no reason to think that the set of files you want
> to tag ever existed (without concurrent changes you don't want)
> at any repository revision.
Exactly. There is no repository revision that matches the files I need
E.G. version 4 of file1 and version 6 of file2 and version 9 of file
a/b/file9 will all have the same label. Since a new version of file1
was checked in at version 7 and a new version of file2 was checked in
at version 8 I don't have a single revision that will match that
So I can set labels to track exactly which files I need to have in a
> That is, there will be a point where
> you commit your last change and have exactly the state you want
> to tag.
There will never be that point in a loosely coupled system. Each
element in the system will be independent and I need to find out what
set of independent files is put in place. I commit my files that have
to be released, but there are 3 other admins with their changes in
testing stages that should not yet be published. So I need a way to
label the verified production files and handle all of the files as a
> Meanwhile other changes you don't want to include until
> the next tag may have been committed before yours. In CVS you
> expect this and you expect tags to identify the state of a workspace
> at the time the tag is created because there is not even a concept
> of repository revisions. Subversion seems to offer an appearance
> of time-sequence order in the repository but no way to really get
> what you want when concurrent changes are possible except in
> a workspace or by making a branch no one else will ever use. And
> creating a branch just to hold what you want in a tag seems like
> overkill when they are fully equivalent.
Yup. Also when you view the file history you are unable to see which
files were deployed as a set since there is nothing that links file1 at
version 4 to file2 at version 6.
> > That is IMHO the crux of the issue and will continue to be until some
> > more natural/orthogonal mechanism for identifying revisions of files
> > that should be treated as a single entity is devised.
> Copying a workspace to a tag is as natural as it gets if you are
> trying to identify exactly that set of files and particularly if
> you are making the last change and committing it because it may
> be impossible to identify that exact set any other way.
At a rate of 10+ tags a day that makes managing the filesystem name
space a bit nuts.
> that you don't forget to commit before the copy, what subsequent
> problems are likely?
It's really ugly and prone to error. I have to:
find the prior tag that the new changes will be based on
check out this tag
svn co http://repo/config/production/release100
switch the files to the trunk release (which I think is impossible,
I would have to switch the ldap directory)
svn switch http://repo/config/trunk/ldap/ldap.conf.solaris ldap.conf.solaris
svn switch http://repo/config/trunk/ldap/ldap.conf.linux ldap.conf.linux
svn switch http://repo/config/trunk/ldap/ldap.conf.aix ldap.conf.aix
update the individual files to the code reviewed versions (and make
sure I don't update other files in the directory by running say
svn up ldap.conf.solaris ldap.conf.linux ldap.conf.aix
create a new tag from the working copy
svn copy . http://repo/config/production/release101
check out the new tag into the distribution system
svn switch http://repo/config/production/release101
With labels I:
svn label -r 195 PRODUCTION http://repo/config/trunk/ldap/ldap.conf.solaris
svn label -r 196 PRODUCTION http://repo/config/trunk/ldap/ldap.conf.linux
svn label -r 199 PRODUCTION http://repo/config/trunk/ldap/ldap.conf.aix
(note no working copy needed). Or maybe:
svn label PRODUCTION http://repo/config/trunk/ldap/ldap.conf.solaris@195 \
Now if I have the files in a working copy at the proper revisions I can:
svn label ldap.conf.solaris ldap.conf.linux ldap.conf.aix
svn up -r PRODUCTION http://repo/config/trunk
for the distribution system. Much easier with a lot fewer steps (2
versus 7) and no working copy to gobble disk space and take minutes to
603-643-9300 x 111
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Nov 21 02:28:59 2006