"Bill Tutt" <rassilon@lyra.org> writes:
> > This won't work, either. The point of `svnadmin deltify' is force a
> > path (perhaps recursively)
> > to be stored as a delta (provided it is
> > space-wise more efficient to do so), instead of as fulltext. Your new
> > calling semantics break down when:
> >
> > - some path A in DELTAREV didn't change in SRCPATH (the most common
> > case, by far).
> >
>
> Nothing wrong with that. The delta is empty, and we don't have any work
> to do, oh darn.
Hm. Weinie's way out. :-(
> > - some path A in DELTAREV doesn't exist in SRCPATH, but was copied
> > elsewhere, or revived in a younger revision (this is an
> > admittedly weird case)
> >
>
> This indeed is annoying, let's not bother letting them recurse. Let's
> just deltify the item that they told us to deltify. You could also
> require that the NodeIDs of that the (DELTAPATH, DELTAREV) and (SRCPATH,
> SRCREV) are equivalent.
Well, yeah, we could do that, I suppose (not recurse, that is). At
this stage, though, the "tool" is becoming so useless that its
existence is questionable.
> > > * Realize that people won't care about this very often, let them suffer
> > > and code as above.
> >
> > Perhaps this should read: Realize that most people won't care about
> > having this functionality at all, and do away with `svnadmin
> > deltify/undeltify' altogether. :-) I almost like the sound of that!
> >
>
> Works for me. Datastores should be as self-maintaining as possible.
> External tuning knobs are bad.
:-) The problem is that without a delta combiner, people like me run
out of stack trying to undeltify some old revisions. The way I see
it, we either need an amazing external deltifier, or we should
internally do our deltification in a less prone-to-infinite-growth
fashion. Perhaps this is where the skip-lists come into play.
> > We know the following things:
> >
> > - To get a successor, you must either clone an immutable node, or
> > copy an immutable node, therefore
> >
> > - No successor of node revision NR has a TXN_ID < NR's TXN_ID, and
> >
>
> Actually this can be false for directories, because of auto-merging.
> e.g.:
> User A begins TXN1, which contains a modification to /foo. (adds file A)
> User B begins TXN2, which contains a modification to /foo. (adds file B)
> User B commits TXN2.
> User A commits TXN1.
>
> Auto-merging causes this TXNID ordering oddity.
This situation currently doesn't make my assertion false (and now I'm
thinking that might be bad).
Currently, the result of this operation is that User A's /foo will
have a predecessor of the /foo in HEAD at the time TXN1 begins. User
B's /foo will have the same predecessor as User A's. Regardless of
the commit order, A's /foo is not a successor of B's /foo, nor
vice-versa. So, given the ordering in your example, asking A for it's
closest successor will return "there ain't one". Same for B.
Um...this is incorrect behavior, isn't it?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 1 14:36:02 2002