On 3/12/07, Kamesh Jayachandran <kamesh@collab.net> wrote:
>
>
> > So, we have four merge steps instead of 7. Conflicts at the first step
> > will leave the tree in the same inconsistent state as the current
> > algorithm. The rest of the steps, though, keeps the whole tree in
> > sync. On conflicts in the first step, we could, as earlier, bring A
> > up to revision four, again risking to introduce spurious conflicts.
> >
> > Another improvements in my proposed algorithm is to avoid merging
> > paths that are going to be deleted later on.
> >
> > I hope this clarifies what I'm trying to get at;)
> Your idea looks cool.
> But I still fail to understand the 'Consistency concern' you have out
> here. Can You explain it?
> Currently only we set 'mergeinfo' on subtree only on successful
> completion of merge.
He means logically consistent. It goes back to an issue I raised in my
thoughts on merge tracking post. In that post I relayed an argument Dan
raised as to why the merge process needs to stop when it runs into a
conflict. The issue was that if a file has conflicts, but you continue
merging all of the other files that you could create a situation where you
have made it difficult for the user to resolve the conflicts because the
context of the files it relates to is not the same. For example, you could
be resolving a conflict where the file is using a function in another module
that no longer exists, has been renamed, changes the parms, etc.
Anyway, I think Peter has been pointing out that with the current merge
algorithm you can easily have that problem anyway and his alternative
approach potentially makes it better. So he is not saying the working copy
is inconsistent in terms of corruption, just that the working copy could be
logically inconsistent making it difficult to resolve conflicts.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on Mon Mar 12 13:47:02 2007