You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Dickie <gr...@max-t.com> on 2002/11/08 14:49:42 UTC
Defining branch life-cycles in subversion
Hi,
I'm trying to put a layer on top of subversion in order to enforce a
development process with things like code reviews, automated merging, etc. I
hace done this before with clearcase. I was thinking I could use unversioned
properties on a branch URL to keep things like state information but I guess
I didn't understand how properties were implemented.
Has anybody done something like this yet? I'm thinking I can maintain the data
somewhere outside of subversion but I'd prefer a more elegant solution if
anyone has any ideas.
Thanks,
Greg
--
Greg Dickie
just a guy
Maximum Throughput
greg@max-t.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Propertites on Revision (not files) (Was Defining branch life-cycles in subversion)
Posted by pw...@mdtsoft.com.
On 8 Nov, Ben Collins-Sussman wrote:
> pwd@mdtsoft.com writes:
>
>> How do you attach propertites (say mdt:eco for an Engineering Change
>> Order Number) to a revisions when you do the commit?
>>
>> The book and quick reference guide don't say as far as I can find.
>
> Oops, sorry, unversioned revision-props have always been part of the
> repository (e.g svn:log, svn:date, etc.), but only recently have
> clients been able to tweak them over the network. We've not yet
> documented the feature anywhere put in 'svn help propset':
>
> svn propset -rN propname propval
So what I have to do is
1) make changes to code
2) do the propset thing above
3) svn commit
Humm I was thinging (and looking) at the commit command.... but I think
that a seperate command..... wait one. what about the following case.
BACKGROUND
we have a thing called an eco (think of it as a bugzilla number) that
an engineer MUST have to make any change to the code.
NOW
I am working on say eco-10501 and eco-10515 and have changed /bar/foo/stuff.c
for 10515 and have change /bas/bas/main.c for 10501.
I have finished 10501 and will
cd /bas/bas and do a svn commit (ecos tend to be from one point in the tree
down)
I will enter my comment (under CVS we have a template with the eco: and
a script that rejects the commit if that is not correct) and commit
if I do the svn propset -rN eco 10501 and forget to do
svn propset -rN eco 10515 before my next commit then I will have the incorect
eco in the commit that takes care of 10515.
I can of course wrap this in a script so that the engineer has to enter
the eco each time.
>
> Also, the UI will be changing soon, so don't habituate just yet. :-)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
--
It is MDT, Inc's policy to delete mail containing unsolicited file attachments.
Please be sure to contact the MDT staff member BEFORE sending an e-mail with
any file attachments; they will be able to arrange for the files to be received.
This email, and any files transmitted with it, is confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error, please advise postmaster@mdtsoft.com
<ma...@mdtsoft.com>.
Philip W. Dalrymple III <pw...@mdtsoft.com>
MDT Software - The Change Management Company
+1 678 297 1001
Fax +1 678 297 1003
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Propertites on Revision (not files) (Was Defining branch life-cycles in subversion)
Posted by Ben Collins-Sussman <su...@collab.net>.
pwd@mdtsoft.com writes:
> How do you attach propertites (say mdt:eco for an Engineering Change
> Order Number) to a revisions when you do the commit?
>
> The book and quick reference guide don't say as far as I can find.
Oops, sorry, unversioned revision-props have always been part of the
repository (e.g svn:log, svn:date, etc.), but only recently have
clients been able to tweak them over the network. We've not yet
documented the feature anywhere put in 'svn help propset':
svn propset -rN propname propval
Also, the UI will be changing soon, so don't habituate just yet. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Propertites on Revision (not files) (Was Defining branch life-cycles in subversion)
Posted by pw...@mdtsoft.com.
On 8 Nov, Ben Collins-Sussman wrote:
> Garrett Rooney <ro...@electricjellyfish.net> writes:
>
>> Greg Dickie wrote:
>>
>> >Hi,
>> >
>> > I'm trying to put a layer on top of subversion in order to enforce
>> > a development process with things like code reviews, automated
>> > merging, etc. I hace done this before with clearcase. I was thinking
>> > I could use unversioned properties on a branch URL to keep things
>> > like state information but I guess I didn't understand how
>> > properties were implemented.
>>
>> why do you want to use unversioned properties? is there anything
>> keeping you from using standard versioned properties?
>
> And anyway, there *are* unversioned properties, but they only exist on
> the revision itself, i.e. they're attached to the tree as a whole.
> The only unversioned props we're using right now are "svn:date",
> "svn:author", and "svn:log". But you're certainly free to attach any
> other unversioned props to trees.
How do you attach propertites (say mdt:eco for an Engineering Change
Order Number) to a revisions when you do the commit?
The book and quick reference guide don't say as far as I can find.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
--
It is MDT, Inc's policy to delete mail containing unsolicited file attachments.
Please be sure to contact the MDT staff member BEFORE sending an e-mail with
any file attachments; they will be able to arrange for the files to be received.
This email, and any files transmitted with it, is confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error, please advise postmaster@mdtsoft.com
<ma...@mdtsoft.com>.
Philip W. Dalrymple III <pw...@mdtsoft.com>
MDT Software - The Change Management Company
+1 678 297 1001 Fax +1 678 297 1003
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Defining branch life-cycles in subversion
Posted by Ben Collins-Sussman <su...@collab.net>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> Greg Dickie wrote:
>
> >Hi,
> >
> > I'm trying to put a layer on top of subversion in order to enforce
> > a development process with things like code reviews, automated
> > merging, etc. I hace done this before with clearcase. I was thinking
> > I could use unversioned properties on a branch URL to keep things
> > like state information but I guess I didn't understand how
> > properties were implemented.
>
> why do you want to use unversioned properties? is there anything
> keeping you from using standard versioned properties?
And anyway, there *are* unversioned properties, but they only exist on
the revision itself, i.e. they're attached to the tree as a whole.
The only unversioned props we're using right now are "svn:date",
"svn:author", and "svn:log". But you're certainly free to attach any
other unversioned props to trees.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Defining branch life-cycles in subversion
Posted by Peter Davis <pe...@pdavis.cx>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 08 November 2002 07:51, Greg Dickie wrote:
> but doing the commits after each pset strikes me as wierd.
If that's the only problem, then you can do "pset" directly on the branch URL
and avoid the separate commit. It will still be a commit, but it only
requires a single command.
$ svn pset branch-status in-review http://server/branch/foo -m "Commit
message."
The argument to -m would be somthing like "Tech Mananger Johnny is currently
reviewing the branch."
By using versioned properties, everyone can see exactly when Johnny started
reviewing, and if any changes were made between when the review started and
when it ends, then Johnny would be able to see that too (for example).
Really, unversioned properties are just a bad idea when versioned properties
have only advantages.
- --
Peter Davis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9y+H9hDAgUT1yirARAgpdAJ48GM0JB5Lr4GorZyVbqZJE1l/oqwCdGMxY
CcVzKJKqiIzMs1XTTXBD9WU=
=4GD6
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Defining branch life-cycles in subversion
Posted by Noel Yap <ya...@yahoo.com>.
--- Greg Dickie <gr...@max-t.com> wrote:
>
>
> The flow is correct but doing the commits after each
> pset strikes me as wierd.
> It will likely work though. I'm also toying with the
> idea of access control
> using the same mechanism, that might be a little
> harder.
According to the help, you should be able to set
properties using full URLs. If so, it should do the
commit implicitly.
Noel
__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Defining branch life-cycles in subversion
Posted by Greg Dickie <gr...@max-t.com>.
The flow is correct but doing the commits after each pset strikes me as wierd.
It will likely work though. I'm also toying with the idea of access control
using the same mechanism, that might be a little harder.
Thanks for your ideas,
Greg
On November 8, 2002 10:43 am, Garrett Rooney wrote:
> Greg Dickie wrote:
> >Well it just doesn't make much sense to me I guess. If I want to know what
> >state a branch is in for example ( working, ready_for_review,
> >rejected,approved ) where would I look for that? I guess I could make it
> > work but then I'd be carrying those properties over on each subversion of
> > the branch directory....
>
> yes, that lets you keep track of when changes to it's status occured and
> things like that... for example:
>
> joe branches to do some development:
>
> $ svn cp http://svn.foo.com/repos/trunk
> http://svn.foo.com/repos/branches/joe-wip
>
> he then sets a property on the branch to indicate it's status (my syntax
> may be off, i don't have svn in front of me right now)
>
> ( in a working copy checked out from joe-wip)
>
> $ svn pset foo:branch-status in-progress .
> $ svn commit
>
> later, he has made some changes, so he emails his technical manager, who
> reviews the code.
>
> $ svn pset foo:branch-status in-review .
> $ svn commit
>
> the manager aproves it, so he notes that and emails joe to tell him to
> merge it in.
>
> $ svn pset foo:branch-status approved .
> $ svn commit
>
> joe merges the branch and notes that it's been merged.
>
> $ svn pset foo:branch-status merged .
> $ svn commit
>
> joe's boss reviews the merge, sees that it has been completed
> successfully, and resolves everything in the bug db. joe now deletes
> the branch.
>
> $ svn rm http://svn.foo.com/repos/branches/joe-wip
>
> is this something like what you were thinking of?
>
> -garrett
--
Greg Dickie
just a guy
Maximum Throughput
greg@max-t.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Defining branch life-cycles in subversion
Posted by Noel Yap <ya...@yahoo.com>.
--- Greg Dickie <gr...@max-t.com> wrote:
> My problem with what what you suggest is that it
> seems like overkill. I need a
> perty onthe overall branch, not every version of the
> branch. If I wanted to
> know what state a particular branch was in would I
> just do "propget status -r
> HEAD
> http://svn.dodo.da/repos/mm/branches/greg-work3" ?
I think you 'know' how Subversion works, but you still
haven't grok'ed the full meaning of versioning the
entire repository.
If you don't mind, I'll step through it (for my sake
as much as for yours ;-)
Each time there's a commit, the /entire/ repository is
versioned. Logically, you can view this as the entire
repository is copied, then the commited change made to
the copy. Physically, it's much more efficient than
that, of course.
So, the HEAD revision /of/, rather than on, the branch
(which, as you know, is just a directory) will have
the latest value of the property. So, the fact that
each version of the branch has the property set should
cause no problems or concerns. In fact, it would give
you the ability to query the state of the branch at
each of its revisions.
HTH,
Noel
__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Defining branch life-cycles in subversion
Posted by Greg Dickie <gr...@max-t.com>.
On November 8, 2002 10:45 am, Ben Collins-Sussman wrote:
> Greg Dickie <gr...@max-t.com> writes:
> > Well it just doesn't make much sense to me I guess. If I want to
> > know what state a branch is in for example ( working,
> > ready_for_review, rejected,approved ) where would I look for that? I
> > guess I could make it work but then I'd be carrying those properties
> > over on each subversion of the branch directory....
>
> I can't tell if you really understand how branches work in subversion
> or not. If you haven't already, be sure to read the Book's chapter on
> branches, or the Design document section on the filesystem. It sounds
> like regular versioned properties are exactly what you want.
>
> If you attach a normal versioned property to a branch (which is just
> an ordinary directory), then it will automatically persist from
> revision to revision. People can come along and change the value of
> the property whenever they want. Your workflow system can query the
> property to know the 'workflow status' of the branch directory. Seems
> pretty simple.
I an new to subversion but I think I understand branches and I did read the
book. They are just copies of the trunk directory with subsequent
modifications correct?
My problem with what what you suggest is that it seems like overkill. I need a
perty onthe overall branch, not every version of the branch. If I wanted to
know what state a particular branch was in would I just do "propget status -r
HEAD http://svn.dodo.da/repos/mm/branches/greg-work3" ?
thanks,
Greg
--
Greg Dickie
just a guy
Maximum Throughput
greg@max-t.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Defining branch life-cycles in subversion
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Greg Dickie wrote:
>Well it just doesn't make much sense to me I guess. If I want to know what
>state a branch is in for example ( working, ready_for_review,
>rejected,approved ) where would I look for that? I guess I could make it work
>but then I'd be carrying those properties over on each subversion of the
>branch directory....
>
>
yes, that lets you keep track of when changes to it's status occured and
things like that... for example:
joe branches to do some development:
$ svn cp http://svn.foo.com/repos/trunk
http://svn.foo.com/repos/branches/joe-wip
he then sets a property on the branch to indicate it's status (my syntax
may be off, i don't have svn in front of me right now)
( in a working copy checked out from joe-wip)
$ svn pset foo:branch-status in-progress .
$ svn commit
later, he has made some changes, so he emails his technical manager, who
reviews the code.
$ svn pset foo:branch-status in-review .
$ svn commit
the manager aproves it, so he notes that and emails joe to tell him to
merge it in.
$ svn pset foo:branch-status approved .
$ svn commit
joe merges the branch and notes that it's been merged.
$ svn pset foo:branch-status merged .
$ svn commit
joe's boss reviews the merge, sees that it has been completed
successfully, and resolves everything in the bug db. joe now deletes
the branch.
$ svn rm http://svn.foo.com/repos/branches/joe-wip
is this something like what you were thinking of?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Defining branch life-cycles in subversion
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Dickie <gr...@max-t.com> writes:
> Well it just doesn't make much sense to me I guess. If I want to
> know what state a branch is in for example ( working,
> ready_for_review, rejected,approved ) where would I look for that? I
> guess I could make it work but then I'd be carrying those properties
> over on each subversion of the branch directory....
I can't tell if you really understand how branches work in subversion
or not. If you haven't already, be sure to read the Book's chapter on
branches, or the Design document section on the filesystem. It sounds
like regular versioned properties are exactly what you want.
If you attach a normal versioned property to a branch (which is just
an ordinary directory), then it will automatically persist from
revision to revision. People can come along and change the value of
the property whenever they want. Your workflow system can query the
property to know the 'workflow status' of the branch directory. Seems
pretty simple.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Defining branch life-cycles in subversion
Posted by Philipp <pi...@users.sourceforge.net>.
On Fre, 08 Nov 2002, Greg Dickie wrote:
>If I get all this working with subversion would anybody else be interested in
>it?
by all means, yes.
please post your experiences to the list.
I'll need to do something similar in the not too distant future.
Bye,
Philipp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Defining branch life-cycles in subversion
Posted by Greg Dickie <gr...@max-t.com>.
I'm starting to the the advantages.
Thanks to everyone who responded, looking forward to participating on the
list.
Greg
On November 8, 2002 11:11 am, Ben Collins-Sussman wrote:
> Greg Dickie <gr...@max-t.com> writes:
> > Yes, you are correct, I can do what you suggest. It just feels wierd
> > to carry that property on all versions of the directory when I would
> > really ever need the latest.... although I guess it could be
> > interesting to document the life-cycle of a particular branch by
> > following the transitions of the property.....
>
> So you just want an unversioned property to attach to the branch
> directory, and "float" along as new revisions appear, so that it's
> just always attached to the HEAD revision?
>
> Subversion is offering you a superset of that. You not only get that,
> but as you say, the entire history of the property is preserved too.
> So you can see that a branch was "completed" in a certain revision,
> "approved" in another revision, and so on.
>
> I guess this is a matter of opinion. IMO, the superset functionality
> is much nicer. :-)
--
Greg Dickie
just a guy
Maximum Throughput
greg@max-t.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Defining branch life-cycles in subversion
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Dickie <gr...@max-t.com> writes:
> Yes, you are correct, I can do what you suggest. It just feels wierd
> to carry that property on all versions of the directory when I would
> really ever need the latest.... although I guess it could be
> interesting to document the life-cycle of a particular branch by
> following the transitions of the property.....
So you just want an unversioned property to attach to the branch
directory, and "float" along as new revisions appear, so that it's
just always attached to the HEAD revision?
Subversion is offering you a superset of that. You not only get that,
but as you say, the entire history of the property is preserved too.
So you can see that a branch was "completed" in a certain revision,
"approved" in another revision, and so on.
I guess this is a matter of opinion. IMO, the superset functionality
is much nicer. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Defining branch life-cycles in subversion
Posted by Greg Dickie <gr...@max-t.com>.
Yes, you are correct, I can do what you suggest. It just feels wierd to carry
that property on all versions of the directory when I would really ever need
the latest.... although I guess it could be interesting to document the
life-cycle of a particular branch by following the transitions of the
property.....
Just curious, is anyone else doing something like this. I had put a system in
place with ClearCase at my last job (BEFORE they put UCM in there) and it
worked really well. All branches were reviewed before they got merged, all
the merges were automated and everything was on the web...
If I get all this working with subversion would anybody else be interested in
it?
regards,
Greg
On November 8, 2002 10:47 am, Noel Yap wrote:
> --- Greg Dickie <gr...@max-t.com> wrote:
> > Well it just doesn't make much sense to me I guess.
> > If I want to know what
> > state a branch is in for example ( working,
> > ready_for_review,
> > rejected,approved ) where would I look for that? I
> > guess I could make it work
> > but then I'd be carrying those properties over on
> > each subversion of the
> > branch directory....
>
> Maybe I don't quite understand the problem. It sounds
> like you should be able to query for the value of the
> property on the HEAD version of the branch. Am I
> missing something?
>
> OTOH, from your last sentence above, and the fact that
> you mentioned ClearCase in your prior email, you may
> be under the impression that Subversion will have
> versions under the branches like the following:
> branch/0
> 1
> 2
>
> Instead, Subversion versions the /entire/ repository
> so you really get something like:
> 0
> 1/branch1
> 2/branch1
> branch2
>
> Please excuse and correct me if I'm making incorrect
> assumptions on your knowledge.
>
> HTH,
> Noel
>
> __________________________________________________
> Do you Yahoo!?
> U2 on LAUNCH - Exclusive greatest hits videos
> http://launch.yahoo.com/u2
--
Greg Dickie
just a guy
Maximum Throughput
greg@max-t.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Defining branch life-cycles in subversion
Posted by Noel Yap <ya...@yahoo.com>.
--- Greg Dickie <gr...@max-t.com> wrote:
> Well it just doesn't make much sense to me I guess.
> If I want to know what
> state a branch is in for example ( working,
> ready_for_review,
> rejected,approved ) where would I look for that? I
> guess I could make it work
> but then I'd be carrying those properties over on
> each subversion of the
> branch directory....
Maybe I don't quite understand the problem. It sounds
like you should be able to query for the value of the
property on the HEAD version of the branch. Am I
missing something?
OTOH, from your last sentence above, and the fact that
you mentioned ClearCase in your prior email, you may
be under the impression that Subversion will have
versions under the branches like the following:
branch/0
1
2
Instead, Subversion versions the /entire/ repository
so you really get something like:
0
1/branch1
2/branch1
branch2
Please excuse and correct me if I'm making incorrect
assumptions on your knowledge.
HTH,
Noel
__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Defining branch life-cycles in subversion
Posted by Greg Dickie <gr...@max-t.com>.
Well it just doesn't make much sense to me I guess. If I want to know what
state a branch is in for example ( working, ready_for_review,
rejected,approved ) where would I look for that? I guess I could make it work
but then I'd be carrying those properties over on each subversion of the
branch directory....
Greg
On November 8, 2002 10:00 am, Garrett Rooney wrote:
> Greg Dickie wrote:
> >Hi,
> >
> > I'm trying to put a layer on top of subversion in order to enforce a
> >development process with things like code reviews, automated merging, etc.
> > I hace done this before with clearcase. I was thinking I could use
> > unversioned properties on a branch URL to keep things like state
> > information but I guess I didn't understand how properties were
> > implemented.
>
> why do you want to use unversioned properties? is there anything
> keeping you from using standard versioned properties?
>
> -garrett
--
Greg Dickie
just a guy
Maximum Throughput
greg@max-t.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Defining branch life-cycles in subversion
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Greg Dickie wrote:
>Hi,
>
> I'm trying to put a layer on top of subversion in order to enforce a
>development process with things like code reviews, automated merging, etc. I
>hace done this before with clearcase. I was thinking I could use unversioned
>properties on a branch URL to keep things like state information but I guess
>I didn't understand how properties were implemented.
>
>
>
why do you want to use unversioned properties? is there anything
keeping you from using standard versioned properties?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org