On Fri, Dec 30, 2005 at 09:40:49PM -0800, Mark Lentczner wrote:
[*1]
> [5b]  cd ~/base/product
>       cvs update -r Branch_Bar
>       darcs record
>       darcs tag
> 
>       cd ~/working/product
>       darcs pull
> 
> While this is a big operation, (several hundred files changed),  
> nothing I was working on changed in any significant way, and indeed  
> there were just a few tiny conflicts.  Darcs was a little slow to do  
> this, but acceptable given the size of the change, and the  
> infrequency of this kind of thing.
> 
> I resolve the conflicts:
> 
[*2]
> [7]   cd ~/working/product
>       #edit files with 'v v v v' in them
>       darcs record
> 
> Now, someone else discovers there is a bit of a mess in Branch_Bar,  
> and fixes something.  This amounts to about 30 one line changes each  
> of several files.  One of those files is one I've been working on,  
> and there will be conflicts.  Indeed about 4 of those lines are in  
> code I've deleted, and about 4 more are lines I've edited.  And this  
> is one of the files fixed in step [7].  Remember, all my edits are  
> recorded in the ~/working repo.  I'll need this change to get  
> Branch_Bar compiling:
> 
[*3]
> [5]   cd ~/base/product
>       cvs update
>       darcs record
> 
>       cd ~/working/product
>       darcs pull
> 
> This never completes.  Never, nada, not ever.  I'm expecting some  
> conflicts in my working area.  I'm expecting I'll have to go in a  
> fiddle with a few conflict markers and re-apply those one line  
> changes myself.  But it never gets there.

A short and incomplete answer (since I'm short on time):
It's often possible to anticipate and avoid this situation by
thinking about "parallel" patches, that is patches recorded
with the same context.

Your work in ~/working/product is parallel to the update in
[*1], and thus causes some conflicts resulting in "first
level" mergers which you cover with resolving patches in
[*2]. This is normal and quite harmless.

Your second update in [*3] is _also_ parallel to all your
work in ~/working/product _and_ to (parts of) the first level
mergers and your resolve patches.  This causes conflicts
with previous conflicts and produces "second level" mergers,
which are exponential in time with current darcs.

In this case you should pull all patches from ~/working/product
to ~/base/product before the second update in [*3] (or at
least the patches that conflicted with the first update
and their resolutions).  Then the record in [*3] will be
"on top of" the conflicts and resolutions and therefore not
be parallel and conflict with them when you pull the second
update to ~/working/product.


-- 
Tommy Pettersson <[EMAIL PROTECTED]>

_______________________________________________
darcs-users mailing list
[email protected]
http://www.abridgegame.org/mailman/listinfo/darcs-users

Reply via email to