[darcs-users] darcs conflicts/dependencies -- is patch theory the place to start?

[AntC]

Kevin Quick <quick <at> sparq.org> writes:

> 
> On Sun, 09 Sep 2012 19:04:15 -0700, AntC <anthony_clayden <at> 
clear.net.nz>   wrote:
> 
> > I'm trying to understand conflicts and why they're so problematic. I saw  
> > in one of the papers an example:
> 
> Without knowing where the original citation came from ...

Thanks Kevin, my later post [sorry for the double-posting] gives the citation 
to papers by Ian L. And see my response to Owen for most of the discussion.

>> [snip]
> One thing to be aware of is that a Create does not include any contents  
> whatsoever.

Yes, I knew that.

> An additional consideration here is how darcs handles patches of identical  
> impact; i.e. are the two Create F patches identical.   If two patches have  
> identical impact, Patch Theory can consider them to be interchangeable.   
> In actuality, the handling of this scenario has been one of the areas in  
> which the darcs implementation has been evolving.

Yes, Owen pointed me to the AddAdd wiki. The problem is that if two patches 
have identical effect (in the same context), is that accidental or are they 
really the *same* patch? For files with standard names (like Makefile), it's 
really hard to tell.

> 
> The pull will come from the repository represented by Fork A.  It will  
> start with your selection Change F, add to it the Create F as a dependency  
> as it commutes backward to O.  Once it reaches O, it has the minimal set  
> of patches required to Then it will attempt to apply that patch bundle to  
> the repository designated as Fork B.  To do this, darcs removes all  
> identical patches from the bundle (as determined by the patch's hash  
> identifier) that also exist Fork B.

Thanks. Owen also described something similar. I hadn't before that seen any 
of the theory papers talking about removing identical patches.

> On a more abstract level, Patch Theory ...  
> ... does not require, nor implement a DAG of patches, and in any particular  
> repository, all patches are active ...

Yes, I kinda get it that a repo is a *set* (or rather, a *bag*) of patches. 
But I'm failing to 'wash out my brain' with the DAG mental model. And it's not 
always easy to think of a patch being the same in two different repos when 
it's morphed en route because of commutations.

> You might also be interested in the following paper:  
> 
http://www.staff.science.uu.nl/~swier004/Publications/PrincipledVersionControl.
pdf
> 

Yes, I've read that, and my other post refers to it for the idea of a file's 
GUID.

The problem with that approach is that a practical VCS only gets to see the 
repo intermittenly (at record points). A lot can have changed (especially 
w.r.t. contents of files). How does the VCS know which files and which lines 
got copied/changed vs. deleted/inserted? How can it keep track of all the 
internal file id's and line id's?

I suppose it could ask the developer, but I can guess what most would say to 
that sort of nit-picking bureaucratic book-keeping.

AntC