> From: cmpilato@collab.net [mailto:cmpilato@collab.net]
>
> "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.
>
Yeah, we said that in the last email didn't we? :)
Let's toss it!
> > > > * 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.
>
Possibly, although my take on it (if we don't have a delta combiner) for
1.0 would be: Screw it, pretend we're Vesta and just don't deltify
anything. As Vesta correctly points out: disk space is cheap, why
complicate something needlessly? ;) I'm sure there are are lots of ther
things that need help besides just undeltification performance work. I'd
honestly only want to try the skip-list stuff if we figured out that a
delta-combiner just wasn't possible with svndiff.
> > > 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).
>
You're algorithm works, but it can generate false failures because your
assertion is bad. (i.e. the only possible successor might be on a lower
TxnID)
> 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.
No, auto-merging should commit the predecessor nodes correctly.
i.e.:
When TXN2 (User B) commits the predecessor is /foo in HEAD at the time
TXN1 begins.
When TXN1 (User A) commits, it's predecessor starts out as /foo in HEAD
at the time TXN1 begins, but gets fixed up by auto-merging to be /foo in
HEAD at the time TXN2 commits.
Whenever I say "auto-merging" I mean the fact that directories have
looser up-to-date-ness rules than files. i.e. the infamous merge()
routine in libsvn_fs\tree.c.
> 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?
>
If the code really did this then yeah, it'd be incorrect, yes.
Thankfully, it doesn't.
The reason this works is because the auto-merging of directory changes
into HEAD when TXN1 is commiting causes newly mutable NodeRevisions to
be created to be the target of the merge() code in tree.c. And of
course, creating a newly mutable NodeRevision initializes the
predecessor correctly. It just so happens that this new NodeRevision has
a TXNID of TXN1. Have I mentioned recently how the word Transaction and
Perforce Changeset concepts are practically synonymous now in the data
model? :)
Subversion is complex.
Lather, rinse repeat. :)
Am I making sense now?
Bill
---------------------------------------------------------------------
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:36 2002