"Bill Tutt" <rassilon@lyra.org> writes:
> > 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!
... as if *you* even needed to answer this particular request for
opinion ... :-)
> > > 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.
I'm either misunderstanding you, or you are misunderstanding the
code. Let's repeat that example:
1. cmpilato creates txn1 and makes a change to /foo/bar.
2. rassilon creates txn2 and makes a change to /foo/baz.
3. rassilon commits txn2
4. cmpilato commits txn1
Now, I just reproduced this case, using gdb to halt cmpilato's commit
at the call to svn_fs_commit_txn() until after a rassilon's commit was
started and finished (so cmpilato got the first txn, but the second
commit). Now, I'm looking at a db_dump of the `nodes' table, and I
see exactly what *I* expected, but what I think *you* would not expect
to see (sorry for being so dense about this).
Please allow me to annotate, C-style:
/* / in revision 0 */
0.0.0
((dir) 0 0 )
/* / in revision 1 (in which I created /foo, /foo/bar, and /foo/baz) */
0.0.1
((dir 5 0.0.0) 0 1 0)
/* / in cmpilato's txn */
0.0.4
((dir 5 0.0.1) 0 1 5)
/* / in rassilon's txn */
0.0.5
((dir 5 0.0.1) 0 1 8)
/* /foo in revision 1 */
1.0.1
((dir) 0 1 1)
/* /foo in cmpilato's txn */
1.0.4
((dir 5 1.0.1) 0 1 6)
/* /foo in rassilon's txn */
1.0.5
((dir 5 1.0.1) 0 1 9)
[...] /* bar's and baz's node revisions follow, but they don't
really matter. */
Now, while auto-merging allowed cmpilato's commit at all -- noting
accurately that while /foo was now out of date, it certainly bore no
conflicting changes -- pay attention to the predecessor IDs in those
skels. cmpilato's /foo and rassilon's /foo both have a predecessor of
the original revision 1 /foo. Am I correct in assuming that you think
that cmpilato's /foo should have assumed a predecessor of rassilon's
/foo during the merge process?
---------------------------------------------------------------------
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:14 2002