Re: Is label support in future release?

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
to tag.

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
label.

So I can set labels to track exactly which files I need to have in a
checkout.

> 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
single unit.

> 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.

> Assuming
> 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')

     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

   and update

      svn up

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 \
          http://repo/config/trunk/ldap/ldap.conf.linux@196 \
          http://repo/config/trunk/ldap/ldap.conf.aix@199

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

 and then

   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
check out.

-- 
				-- rouilj
John Rouillard
System Administrator
Renesys Corporation
603-643-9300 x 111
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org