Re: [Gnu-arch-users] Completely distributed development

[Matthieu Moy]

David Allouche <address@hidden> writes:

> How was the reversion done?

Just undoing the change with  my text editor, saving, committing. (was
a trivial change inside a bigger patch)

That could have been any edition of the same portion of text (it would
have raised a conflict instead of an inconsistant behavior). 

Even if you  don't do anything that would raise conflict,  if you do a
normal  merge, without  --forward, you  always get  conflicts  for any
modification made that is merged  twice. Well, you could say "you have
--forward,  so why  complain?". Well,  I  think it's  better to  avoid
sources of conflicts than to eliminate conflicts afterwards.

> instead of the (in that case) more correct:
>
>    tla replay --reverse REV
>    tla sync-tree [*]
>    tla commit

I  think this is  equivalent to  reverting the  file manually  as I've
done. 

> If there had been a sync-tree, merging B->C would have caused a conflict
> because the patchlog of the bad patch would have already been present in C.

I  never  got conflicts  in  that  situation.  Perhaps because  I  use
star-merge --three-way,  but I don't  think tla raises  conflicts when
you merge a  patch if one of the patch-log  entries is already present
in your tree anyway.

>> In our example, if "C" had merged from "B" first, he would have merged
>> the wrong  patch, and the wrong  patch would have  disapeared from the
>> list of missing patches from "A"  for "C". Then, "C" would have merged
>> the remaining missing patches,  which contain the patch revertion.
>
> That also holds if sync-tree is used. So your problem seems solved.

Anyway, no:  I don't want something  telling me "you  merged the wrong
patch.  Too late!",  but something  telling  me "here's  the patch  to
merge".

>> The answer is : Merge first  the patches that haven't been merged from
>> other partners yet.
>
> Seems like a useful operator for fully-distributed development... But it
> must be implemented carefully to behave consistently when commits occurs
> concurrently. The listing of existing revisions of each version must
> only be fetched once.

I  don't  say  this  method  avoids 100%  conflicts.  You  always  get
conflicts when peole edit the same portion of file at the same time. 

*BUT* there is a trivial case that should be managed trivially too: If
it never  happens that two persons are  working on a file  at the same
time, and  if everybody merge before modifying,  then, there shouldn't
be any conflicts.

In a centralized version control, if it never happens that two persons
modify the same file at the same time, and if you update before making
modification, then  you never  have to merge  anything. Why  would you
have to with a distributed version control? 

> I can see how that could be implemented:

I was thinking of something similar, yes. 

Now, the  question is:  will it  be implemented in  tla, or  should we
implement it in xtla? I didn't look too much at the code of tla, and I
think this would take less time  _for me_ to implement it in xtla, but
I also think other tla users  (and non Emacs users) would like to have
it!

> Yet, I think your problem can be more simply solved by correct reversion
> of erroneous patches.

That's where we disagree ;-)

-- 
Matthieu