On Mon, 2006-11-20 at 19:28, John Rouillard wrote:
> > >
> > > 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.
What 'couples' it at all then? The scenarios I've pictured
all involve being able to reproduce some existing set of
files that have been together. Are you saying you want
to attach a label to some arbitrary set of files without
ever assembling them in a workspace?
> 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.
You can commit yours to the trunk where they will accumulate
a change history and copy to a tag where they are easy to
find. Who decides that they are verified and that the set is complete?
> > 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.
Do you expect to run out of sequential numbers?
> > 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
You'd need that information regardless of what it is.
> 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')
Is this all arbitrary concerning who will want what files in their
workspace or a continuing story? I'd expect the next round to
involve keeping the previous workspace, updating to pick up
whatever other work is current. But if these files
really don't have anything to do with each other what's the
point of putting them together and then fighting over which
version is which? Why not give them their own branches or at
least subdirectories, with the last operation by whoever is
blessing them as ready being to merge or move them to the right
place so updates always pick up the right versions.
> 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:
If multiple people are committing all the time, how do you know
which rev's you want together?
> 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.
Someone has to have a working copy or they can't make changes
or do any testing. Can't the last person to change it copy
to the tag?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 21 05:40:19 2006