> > Random questions and answers
> > Can we do without the revprop portion of this design?
> > Technically yes, AFAIK, but it may require more crawling and querying at
> > merge time.
>
> I am not sure why this would be true. Revprops are not stored in the WC,
> so won't this require a lot of repository access to retrieve the revprops?
> Or do you envision all of this happening on the server anyway?
Almost all of the "determining what we want to merge in" part of history
sensitive merging part will have to happen server side no matter what ew
do, because in no design other than keeping the repo local do clients
ever have as much info as the server. Thus, if you wanted the a
absolute best job, you'd still have to do it server side. Unless we
really want to try to keep *all* the merge history for an entire repo's
history client side, and keep it in sync.
The "efficiency" part is just because in our current backend fs designs,
revprop access is much faster than random dir property access.
Of course, this may be a complete wash anyway, because you have to get a
bunch of info about those dirs *anyway*.
As I said, i seesaw back and forth about whether to deal with revprops
at all because if you don't, you get the following advantages:
1. Much easier auditability
2. Don't need to care about wc roots/commit-roots
3. Don't need to try to bring revprops from rev to rev.
There is always some server contact in merges right now, except wc-wc
merges.
The only thing putting *any* of this in the client buys you is that the
latest version of the merge history for your *target* is there (in the
form of dir/file props), and is editable. Of course, with revprops,
that's not quite true :(
Source url merge history is always going to need to be looked up in some
manner.
I'm literally about 5 seconds away from throwing away the revprop part
of storage, because it just seems to make things significantly more
confusing.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 28 19:35:05 2006