Am 03.12.2011, 07:13 Uhr, schrieb Stephen J. Turnbull <[email protected]>:
> Example: I'd want to manage object library files (graphic objects,
> organized in libraries stored as ASCII text) through darcs. Darcs
should > only identify single hunks using specification in the user
recipe. > Goal:
> prevent the creation of too many hunks caused by alternating lines
within
> an information entity that are modified, and lines in between that
are not
> modified.
What do you mean be "too many hunks"? Why is "many hunks" a problem?
Well, a hunk is actually an identified unit with an index (when I'm
right). According to the famous camp webcast, this can be used to extract
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. For this to work optimally in a given sort
of file structure that is to be versioned, it would help when darcs can be
"instructed" how to identify hunks (e.g. via regexps in a prehook). In the
current state of darcs, when e.g. a library element of a library file is
changed, darcs could identify several hunks of one single element, when
some lines in this element are changed, and others are not changed. This
way, hunks are not very meaningful, and would also hinder efficient
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.
Note that the source code example solely serves this purpose and not more
than that. My idea of "smart" hunk assignment will especially be useful
with repos that contain only a small amount of large files, as is mostly
the case with libraries, or even some script code out there, e.g. gitk.
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
