On Tue, Jan 27, 2009 at 18:00, Petra Margaritoff
> Thank you for the quick reply!
>> 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.
> You are right, properties would be just the thing. To my knowledge though, properties are available only
> - either for ALL files of ONE revision (versioned properties)
> - or for ONE file in ALL revisions (unversioned properties)
> What I would need is a property I can set on a file basis and which is valid for only one revision, say
> foo.c rev. 44 - PEER_REVIEWED_OK
> foo.h rev. 42 - PEER_REVIEWED_NOK
> foo.h rev. 43 - PEER_REVIEWED_OK
Well... you could have some kind of structured value in the revision
property. How many files are you talking about? revprops aren't
supposed to be very big, but if you're talking about a few dozen
files, then it could work.
One interesting approach would be to make a copy of whatever
snapshot-revision you're looking at. And then "all files in this copy
should be reviewed." When they get reviewed, then delete them from the
copy. When the copy is empty, then everything has been reviewed.
If you're talking about seldom-changed files, and want to carry review
information forward, then attach a versioned property to it. No big
deal to create a new revision to mark the change. However, whenever a
file changes, that property would need to be reset to "needs a
review". You could have a pre-commit hook to ensure that all changed
files have a reset property (the hook *cannot* modify the properties
itself). Then, when you go to make your release, you can verify that
all files have the "reviewed: ok" property on them.
Something like that....
Received on 2009-01-27 18:32:11 CET