monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] file suturing considered tricksy


From: Nathaniel Smith
Subject: [Monotone-devel] file suturing considered tricksy
Date: Thu, 19 May 2005 22:51:47 -0700
User-agent: Mutt/1.5.9i

"File suturing" is taking two logically distinct files, and smushing
them into a single file in a merge.  So, for instance, if you and I
both add a file with the same name, and then we merge, currently
monotone will happily let you do a 2-way merge between those files's
contents, and then consider them the "same file" in the future.  Use
cases would include when two people accidentally add a file with the
same name, or when Peter Simons does his clever combined repository of
autoconf macros.

So, I've _finally_ managed to figure out why my hind brain has been
jumping up and down at me for the last 6 months about this.  It's
because of the following scenario:

   A   B
  / \ /|
 |   X |
 |  / \|
 | C   D
 |/
 E

Suppose A has "add foo", B has "add foo", D is a simple merge, so D
contains a single sutured file name "foo".  Suppose also that C has
"rename foo bar", and E is a simple merge, so E has two files "foo"
and "bar".

Now, I merge E and D.  What happens?

The best answer I know is "we have a name conflict between 'foo' and
'bar'".  This is rather nasty to detect, resolve, etc.  What makes it
especially bad is that it can lead to n-way name conflicts and
contents conflicts -- already in the example above there are three
distinct file contents, that all have to be somehow merged; in the
general case, where more files have been sutured together on one side
and left unsutured on the other, then there are arbitrarily many
conflicting names, and arbitrarily many file contents to merge
somehow.

Another nasty thing about this is that in the precise codeville-merge
context, "suturing" two files together is quite tricky -- even if the
two files to be merged are similar (or even identical!), done naively,
we will have to pick just one side to win the merge, at least for each
line.  And that means that when we later go to merge again, everything
will conflict, even if there's no reason for it to.  This would
destroy the utility of this trick for Peter's autoconf macros use
case.

Probably all of these things are fixable, given sufficient work, and
the feature really is _nice_ to support, but... it looks nasty to
make work right, and we have enough ahead of us that I'm sort of
leaning towards just not supporting file suturing at all, at first.

Of course, that leaves the question of what to do with existing file
sutures when migrating history; I guess we can just decide that it
wasn't a suture, it was a clobber, and just one (arbitrarily chosen)
side "won".

Comments?

-- Nathaniel

-- 
"On arrival in my ward I was immediately served with lunch. `This is
what you ordered yesterday.' I pointed out that I had just arrived,
only to be told: `This is what your bed ordered.'"
  -- Letter to the Editor, The Times, September 2000




reply via email to

[Prev in Thread] Current Thread [Next in Thread]