> -----Original Message-----
> From: Gavin Lambert [mailto:gavinl@compacsort.com]
> Sent: Monday, December 19, 2005 6:46 PM
> To: 'List Subversion'
> Subject: RE: Labeling techniques
>
> Quoth Phil Endecott <mailto:spam_from_subversion_users@chezphil.org>:
> > Erik, why is it important to you that the revision number doesn't
> > change when you change the status of a file? It seems like an
> > unnecessary restriction to me. Perhaps you are putting too
> much value
> > on the repository revision number. It is just a number.
>
> I think what Erik was hinting at was this sort of scenario:
>
> 1. Commit some changes to a group of files as revision #245.
> 2. QA group updates to revision #245 and begins testing.
> 3. Commit some other changes (potentially overlapping) as
> revision #246.
> 4. QA group approves revision #245, and wants to mark all
> changes in it as approved (or possibly even approve some
> changes and deny others) -- but they don't want to approve
> anything that happened in #246, and AFAIK property changes
> can only be made to the HEAD revision...?
>
> If this is the case, then I think branching is the way you'll
> have to go. Copy revision #245 to an "approved" branch; once
> #246 is tested and approved, merge those changes in too. And
> so forth.
>
That's pretty much it. We may have to use branching to accomplish our
goals; I'm also going to investigate properties further. I agree with
Phil that properties should be able to do what I need, but I'll have to
do some more thinking on translating the labeling scheme currently in
use here to something that we can easily insert/update/select with the
svn prop* tools and some scripting.
Thanks for your help.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Dec 20 18:42:41 2005