On Thu, Nov 16, 2006 at 07:02:10PM +0000, Phyrefly wrote:
> On 16/11/06, John Rouillard <rouilj@renesys.com> wrote:
> > label: a property on a file svn:label associated with the newest
> > revision of a file. Multiple labels can be set using
> > propedit. The label property is a label name followed by the
> > file revisions (repository revision of the changes to the
> > file) that should be labeled. E.G.
> >
> > PRODUCTION: 2 20
> > TEST2:2 10
> >
> > would make 'svn up -r PRODUCTION' extract the contents of the
> > file at repository revision 20.
> >
> > So I have the following labeled entries in trunk/:
> >
> > file rev labels latest changed revision
> > foo1 2 PRODUCTION 20
> > 2 TEST
> >
> > foo2 22 PRODUCTION 22
> >
> > a/foo3 10 PRODUCTION 13
> >
> > b/foo4 10 TEST 13
> >
> > [...]
> >where "rev" is the newest revision for the label.
> >It might be possible to do this using un-versioned properties as well
> >to set the label list on the latest version.
> >
> >Ideally, I could just use --revprop svn:label:PRODUCTION on any
> >arbitrary revision of a file and svn would automatically choose the
> >latest revision with the tag. If I needed to get to an earlier state,
> >I would just use a peg revision in the update/checkout URL.
> >
> >However it would require traversing down the version tree for the file
> >and might be expensive. Also you can change the revprop's and screw up
> >the ability to retreive a prior release using a peg revision.
> The only thing I'd add is this: If you're going to keep any history at
> all for labels (which I'm not sure is necessary) - then the date of
> the change should probably be kept too. This will tell you when
> PRODUCTION became rev 20, as opposed to rev 2, for example. (and thus
> which rev was given to a client that you did a build for on a specific
> date).
Hence arguing for it being a versioned property of the file so
you get a datestamp automatically.
--
-- 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
Received on Fri Nov 17 15:53:55 2006