You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Granse, Erik (STP)" <er...@guidant.com> on 2005/12/19 17:18:41 UTC
Labeling techniques
We're trying to do something a little more file-centric than Subversion
likes and I'm looking for thoughts on our problem.
We have a need to identify particular revisions of particular files as
'baselined' (e.g., completed peer review, etc.). We need to be able to
identify all files that have been baselined (and ideally, all files
which have not been). A file may be re-baselined if changed. We've
thought through a few different strategies and haven't found one that
works well.
- Adding baseline information to the commit message won't work because
the file has to be committed to perform the peer review prior to
labeling it baselined.
- Revision properties are a possibility, but we'd want to associate the
property to a specific file. Conversely, file properties don't allow us
to also associate the property to the file at a specific revision.
Further, we run into the same problem as above, with doing a recommit of
the file in order to add the property.
- The Subversion tagging mechanism has limitations for dealing with
files. If we tag a file into tags/baselined, we then have to browse the
tags directory to learn which files have been baselined rather than
being able to keep that information with the file in the trunk. Also, we
won't be able to re-baseline a file without deleting it and recopying it
or else maintaining a large directory tree to accommodate multiple
baseline revisions. The former method means that we can't do a log on a
single file to see baseline history and the latter method would just be
a mess.
Any advice you can offer would be appreciated.
Erik Granse
Software Engineer
Tel 651.581.3597
Re: Labeling techniques
Posted by Scott Palmer <sc...@2connected.org>.
On 19-Dec-05, at 12:18 PM, Granse, Erik ((STP)) wrote:
> We're trying to do something a little more file-centric than
> Subversion likes and I'm looking for thoughts on our problem.
>
> We have a need to identify particular revisions of particular files
> as 'baselined' (e.g., completed peer review, etc.). We need to be
> able to identify all files that have been baselined (and ideally,
> all files which have not been). A file may be re-baselined if
> changed. We've thought through a few different strategies and
> haven't found one that works well.
...
> - The Subversion tagging mechanism has limitations for dealing
> with files. If we tag a file into tags/baselined, we then have to
> browse the tags directory to learn which files have been baselined
> rather than being able to keep that information with the file in
> the trunk.
You could possibly use 'svn switch' on the files that are baselined.
Then they would show up as switched when you did 'svn status'.
But that does carry over to the WC on other checkouts. You would
have to do something different for that.
> Also, we won't be able to re-baseline a file without deleting it
> and recopying it or else maintaining a large directory tree to
> accommodate multiple baseline revisions. The former method means
> that we can't do a log on a single file to see baseline history and
> the latter method would just be a mess.
Having a 'baseline' branch seems to make sense. Perhaps you could
combine that with some scripts that would 'svn switch' only the files
that were also available in the baseline branch?
Scott
RE: Labeling techniques
Posted by Gavin Lambert <ga...@compacsort.com>.
Quoth Phil Endecott <ma...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Labeling techniques
Posted by Phil Endecott <sp...@chezphil.org>.
Ryan Schmidt wrote:
> On Dec 19, 2005, at 20:45, Phil Endecott wrote:
>> Granse, Erik (STP) wrote
>>> - Revision properties are a possibility, but we'd want to associate
>>> the property to a specific file. Conversely, file properties don't
>>> allow us to also associate the property to the file at a specific
>>> revision.
>>
>> On the contrary, file properties are associated with particular
>> revisions. You can set a "status" property to "approved" and commit
>> it, and it's that particular revision that is affected. Subsequently
>> you can change the status property to "released" and commit that.
>> The log will show you which properties changed in which revisions.
>
> Phil, I'm pretty sure Erik had it right in the first place. There are
> two kinds of properties in Subversion:
>
> * Versioned properties are attached to specific files and directories,
They are recorded for particular revisions of particular files and
directories. Through a file's history, its properties can change. If
you look at an old revision of a file you'll see the properties that
applied at that time. This gives the sort of per-file status record
that Erik needs.
> and to apply or remove them, you increase the repository revision
> number.
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 you need is what many people do when we declare that a file
or feature is "frozen", "stable", "approved" etc. Setting properties on
files to indicate this is a good way to solve the problem. You can
write yourself a script that will call "svn propget" and show you the
status of a file, find files that don't have a particular status, etc.
You can also have hook scripts that would, for example, allow only
certain users to change files that are "frozen".
(I'd be interested to see if any of the web-based repository browsers
can view properties to support this sort of thing, e.g. colour-coding
files based on status.)
--Phil.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Labeling techniques
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Dec 19, 2005, at 20:45, Phil Endecott wrote:
> Granse, Erik (STP) wrote:
>
>> - Revision properties are a possibility, but we'd want to
>> associate the property to a specific file. Conversely, file
>> properties don't allow us to also associate the property to the
>> file at a specific revision.
>
> On the contrary, file properties are associated with particular
> revisions. You can set a "status" property to "approved" and
> commit it, and it's that particular revision that is affected.
> Subsequently you can change the status property to "released" and
> commit that. The log will show you which properties changed in
> which revisions.
Phil, I'm pretty sure Erik had it right in the first place. There are
two kinds of properties in Subversion:
* Versioned properties are attached to specific files and
directories, and to apply or remove them, you increase the repository
revision number.
* Revision (non-versioned) properties relate to a specific revision,
but are not bound to specific files or directories.
On Dec 19, 2005, at 18:18, Granse, Erik (STP) wrote:
> We have a need to identify particular revisions of particular files as
> 'baselined' (e.g., completed peer review, etc.). We need to be able to
> identify all files that have been baselined (and ideally, all files
> which have not been). A file may be re-baselined if changed. We've
> thought through a few different strategies and haven't found one that
> works well.
Erik, it sounds like you should consider having a trunk, where
development occurs, and a "reviewed" or "baselined" branch, to which
approved changes are merged.
When we deal with changes in our project's source code, we don't talk
about changes in files; we talk about changesets or revisions.
Implementing feature X may involve adding a block to an HTML
template, adding new images, adding methods to database abstraction
classes, calling them from the business logic files, and more. All
this together is a single changeset or revision. If we were to have a
trunk and a baselined branch, someone intending to move the feature
to the baselined branch would need to review all these changes as a
whole, not individually, and would also not need or want to concern
themselves too much with other parts of the affected files which may
relate to other features long since finished. Of course, if you're
not managing code but some other kind of files, this
interrelationship between files may not exist for you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Labeling techniques
Posted by Phil Endecott <sp...@chezphil.org>.
Granse, Erik (STP) wrote:
> - Revision properties are a possibility, but we'd want to associate the
> property to a specific file. Conversely, file properties don't allow us
> to also associate the property to the file at a specific revision.
On the contrary, file properties are associated with particular
revisions. You can set a "status" property to "approved" and commit it,
and it's that particular revision that is affected. Subsequently you
can change the status property to "released" and commit that. The log
will show you which properties changed in which revisions.
Have a look at the start of the Properties chapter in the book:
http://svnbook.red-bean.com/nightly/en/svn.advanced.props.html
--Phil.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Labeling techniques
Posted by "A.T.Hofkamp" <a....@tue.nl>.
Granse, Erik (STP) wrote:
> We're trying to do something a little more file-centric than Subversion
> likes and I'm looking for thoughts on our problem.
Yesterday I thought about tags being labels rather than directories as
currently implemented in svn. In my mind grew the idea of having a tags file
instead of a directory, ie instead of "svn copy /trunk /tags/LABEL", why not
have a file with lines like
LABEL1:5423
LABEL2:5987
etc
in the repository.
With branches, there should probably also be a branch field, or maybe a root
directory with peg revisions?
For example, something like
LABEL1:/trunk@5423
LABEL2:/branches/shuffling@56987
?
With a few scripts that make the information easily accessible, it may be a
flexible way of handling tags.
You could even tag individual files, although I don't see any use for this in
our environment.
I have no idea what happens with tagging if you apply this idea. On the other
hand, it does seem very flexible, tagging files and baselining files should be
possible.
Maybe you can use something like this to solve your tagging problem.
Albert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org