[darcs-users] hunk pattern recipe

[Maris, Rob]

Am 03.12.2011, 15:52 Uhr, schrieb Stephen J. Turnbull <stephen at xemacs.org>:

>  > the "history" of a single text chunk within a file, without being
>  > cluttered by information of other chunks that is particularly not of
>  > interest in a given situation.
>
> Somewhat like the git pickaxe?

No. See below (BTW: thanks for attending me).

>  > hunk-by-hunk record. When versioning source code, just as another  
> example,
>  > a function or data struct could be defined as a hunk entity:  
> regardless
>  > how many hunks are identified within the scope of a function (in  
> "current"
>  > darcs), a recipe could join those hunks to form a hunk per function or
>  > struct.
>
> This would make sense in git (I've actually toyed with the idea of
> adding a file object to git, so that blobs would be members of files;
> the main idea was to make each defun a blob).  In Darcs, though,
> AFAICS it would get in the way of the main idea, that "primitive
> patches" can often commute, because the bigger the hunk the more
> likely it will not commute with another primitive patch.

I believe I understand this limitation. But, in the case of e.g.  
versioning a component library file of a CAD system library, several hunks  
within the range of a single component could merge without conflict. But  
in such a case, every hunk that is part of a component (with delimiters to  
adjacent components defined in the prehook regexp file) and that is  
changed on both sides of merge input must always flag a conflict. In other  
words: hunks that have the size of file portions in between identified  
delimiters would inherently flag a conflict: thus, such a limitation as  
you indicated is wishware here.

> So I think you may have something here, but it's going to be very
> delicate to implement.  On the one side, it seems likely to impair
> patch theoretic manipulations in source code files, and on the other
> AFAIK Darcs is no smarter than any other major VCS wrt to files that
> are not line-structured: it basically just stores the whole thing as a
> blob and doesn't try to diff it.

Well, whether Darcs is no smarter than any other major VCS: I can't judge  
that. I'd feel that much is true about this, since there seems not very  
much momentum in Darcs development, not to speak of its fork camp.