You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by cm...@collab.net on 2002/05/30 06:21:55 UTC
Saying goodbye to `svnadmin deltify' ?
"Bill Tutt" <ra...@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).
> 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}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Saying goodbye to `svnadmin deltify' ?
Posted by cm...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> On Thu, 2002-05-30 at 02:21, cmpilato@collab.net wrote:
> > 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!
>
> Perhaps you'd want to re-deltify it if we ever implement skip-deltas.
> Then you'd save space without having deep deltas.
>
> Or perhaps you'd want to re-deltify it if we ever have a working delta
> combiner. Then having lots of small deltas between here and there
> doesn't hurt so much.
>
> Or both.
>
> I don't know how important it is to have the feature, but your argument
> doesn't seem to hold.
To have the functionality today means I have to invest more time on
these discussions about which hackish or painfully inefficient way to
implement it, and for no real gain (because of the lack of better
deltification). Not to mention that the functionality will likely
have to be rewritten later to make use of whatever deltification
improvements come along in the future.
To re-add this functionality *later* when it will actually be useful
costs nothing today (except a quick edit to comment out the
functionality in svnadmin).
I am *seriously* not trying to get out of doing work here -- if there
was a Good way to accomplish this task today, I'd be all over it. But
there really isn't a good way to do it Right (that I've seen proposed
so far).
I just want someone to tell me that they need `svnadmin deltify'
today, 'cause I have a feeling nobody but me has ever even used it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Saying goodbye to `svnadmin deltify' ?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2002-05-30 at 02:21, cmpilato@collab.net wrote:
> 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!
Perhaps you'd want to re-deltify it if we ever implement skip-deltas.
Then you'd save space without having deep deltas.
Or perhaps you'd want to re-deltify it if we ever have a working delta
combiner. Then having lots of small deltas between here and there
doesn't hurt so much.
Or both.
I don't know how important it is to have the feature, but your argument
doesn't seem to hold.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Saying goodbye to `svnadmin deltify' ?
Posted by Bill Tutt <ra...@lyra.org>.
> From: cmpilato@collab.net [mailto:cmpilato@collab.net]
>
> "Bill Tutt" <ra...@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