--- Brian Huddleston <brianh@huddleston.net> wrote:
> > Perhaps what you *really* want is a "svn
> revpropfind" command which
> > makes it easy to run queries against property
> data? This would
> > make it relatively simple to do:
> > svn co -r`svn revpropfind --firstonly eq
> svn:label Build_123 $URL` $URL
> > Some of the metadata in the repository is a
> little hard to get at
> > right now (read: not as efficient as it could
> be).
> Yes, that would be awesome.
While that may solve some of the issues raised, it
would still not be fully elegant or well-done as it
would be clunky and simply a hack in the system to get
it done.
Personally, I think the best way to do it would be to
add another table into the database containing nothing
more than a revision number and label. The label must
be unique, so it would be the primary key. And
multiple labels could be assigned to a single revision
number. More over, the table would not increment the
revision numbers in the system. Ideally, it would
still show up in a repo dump, but even if it required
a special dump (e.g. svn dumplabels), it would still
be a better thing.
In order to avoid the name space collision:
a) perhaps there is a table for each directory so that
all directories can have their own labels.
b) each label must be uniquely named. An admin update
would allow for a name change or revision number
reassociation (e.g. Rc_1 -> RC_1, and RC_1 = 5 -> RC_1
= 25, respectively).
This shouldn't introduce any backwards compatibility
issues since it wouldn't affect the data, just add new
functionality. Clients that didn't know about the
functionality wouldn't be querying it. Likewise, if a
client knew about it, and the server didn't, then the
client could disable the functionality and record a
FAQ saying 'upgrade to this version to get
functionality X'.
The above would really solve the problem.
BRM
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 11 22:24:42 2005