> From: cmpilato@collab.net [mailto:cmpilato@collab.net]
>
> "Bill Tutt" <rassilon@lyra.org> writes:
>
> > > :-) 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.
>
> Actually, I was thinking (watch out), and I realized that my brain was
> treating `svnadmin deltify' and `svnadmin undeltify' as a pair, like
> you had to have both, or neither. This is simply bogus. `svnadmin
> undeltify' is mindless to implement (indeed, should still work today,
> though `svnadmin deltify' does not) AND is actually useful. That is,
> right now if I want to be able to dump revision 278 of a copy of the
> Subversion filesystem, I need to undeltify some revisions after 278 so
> my deltas for that revision aren't so darned deep. And you know what?
> I'll never want to re-deltify that, because then I'll be in the same
> ill state I was in when I started!
>
> LIST-FOLK: If you think we need to keep `svnadmin deltify' around,
> you better let me know soon, 'cause she's about to disappear!
> `svnadmin undeltify' will stay, though (it scratches my itch).
>
Killing it is fine by me. Die die die!
> > No, auto-merging should commit the predecessor nodes correctly.
>
> Oh...um...the merge code doesn't (any more) do any cloning whatsoever.
> That code has been ripped out. Hm. Looks like I have some more work
> to do. {grumble, mumble}
>
Err. The case I mentioned to cause you to go into apoplexy is covered
by:
For Every E not in Ancestor:
....
/* E does not exist in target */
if (! t_entry)
{
/* target takes source */
if (! svn_fs__dag_check_mutable (target, txn_id))
return svn_error_createf
(SVN_ERR_FS_NOT_MUTABLE, 0, NULL, trail->pool,
"unexpected immutable node at \"%s\"", target_path);
SVN_ERR (svn_fs__dag_set_entry
(target, s_entry->name, s_entry->id, txn_id, trail));
}
Having a mutable NodeRevision in target, should cause the right thing to
happen here.
For the case of the code that I think you were talking about. (logic
case 2 in your new code) There also isn't a problem, because merge gets
invoked recursively, which creates mutable NodeRevisions.
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:16 2002