[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

filesystem merge() behavior

From: <cmpilato_at_collab.net>
Date: 2002-05-30 15:32:12 CEST

"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

This is an archived mail posted to the Subversion Dev mailing list.