Andreas Schweigstill <andreas_at_schweigstill.de> wrote on 01/27/2009
> Petra Margaritoff schrieb:
> > We have a similar issue: We would like to place "labels" or "tags"
> > on certain revisions of certain files in order to mark them as
> > "peer reviewed", "integration-tested" etc. Having done that it is
> > easy to check, whether all files of a revision have undergone the
> > required QA measures.
> For such purposes using custom Subversion properties can be a good
> solution. Properties won't be confused with normal tags or label
> and can also use their own "namespaces". And they can not only be
> used as a flag but they also can contain some more verbose information.
> Unfortunately Subversion itself currently doesn't support queries
> based on user defined propertiert, like
> svn export --with-property=my:prop1 --without-property=my:prop2
> But such things can be done very easily with some shellscripts.
User properties are file based, not revision based. This
would not work for identifying a specific revision of a
file as "peer-reviewed". revision properties can apply to
multiple files, so they won't work unless your scripts are
smart enough to handle that appropriately.
Using properties would also make it difficult to create
a working copy of the files with the specific property.
We were originally going to write some utilities to help
the user delete and recopy files from one branch to another.
(To simulate moving labels)
However, we just recently noticed this will change
the "last changed revision number" when used for
individual files. (Copying folders works fine,
since the last changed revision of the files it
contains are not updated.) This makes it inappropriate
for flagging peer-reviews, since we use the
files last changed revision number as identification
to indicate when a peer review is needed. (Adding
the "peer-reviewed" property would also change this number)
NOTE: Our internal peer review tool tracks this information
outside of Subversion in it's own database, which is
probably a "better" way to do this. However, it makes
it more difficult for the user to see what has been
reviewed outside of the peer-review tool if they
are used to looking at traditional CM labels for this
Another option is to (abuse) v1.6 file level externals and
create scripts to manage these properties to simulate
labels... You can then easily "checkout" the current
peer-reviewed files into a working copy and you can
easily update individual files in this directory by
manipulating the file level external properties without
affecting the last changed revision number.
This biggest problem with externals is that tools like
TortoiseSVN don't show externals via the repo-browser
interface, so it is difficult to see the contents of
the "label" without first checking it out or creating
some special viewer tool.
Received on 2009-01-27 19:12:59 CET