>>>>> "Juliusz" == Juliusz Chroboczek <[EMAIL PROTECTED]> writes:
>> I suspect you already see this, but to give other people an
>> idea of what we're talking about, let me unpack that. I see no
>> reason you can't put a patch in a blob.
Juliusz> Interesting suggestion. What does it buy you?
A standard exchange format. :-) More important, a standard exchange
format which is a content-addressable store. Eg, any "name to object"
convention or UI or database schema that the Linux people come up with
is immediately applicable to Darcs patches.
What I think is an immediate advantage for Darcs is that in exchange
for a one-time change of format, (1) you get pristines and/or revision
libraries in a format that is not subject to corruption by typical
recursive operations by developers, and (2) you get to leverage UIs
and schemas that address Git content. (2) is a bet that they'll be
developed, of course, but I think it's a good one given the amount of
effort that goes into anything Linux-kernel-related.
A digression on why I want this personally (which need not appeal to
you, my case for a change to Darcs is the above):
Something that has frustrated me for a long time is the fact that SCMs
and editors are quite separate, and SCMs (with the single exception of
darcs's token replace patch AFAIK) are entirely clueless about the
syntactic structure of the objects they manipulate.
For example, darcs's patch algebra uses directory structure. If two
patches touch none of the same files, they commute trivially. But by
the same logic, two patches that are restricted to non-intersecting
defuns commute. A patch whose textual changes are entirely contained
in a defun commutes trivially with a patch which exchanges that defun
with another one.
Now, there are good reasons why we don't do defun-per-file. And there
are good reasons why the working files should be text/plain. But with
an efficient content-addressable store and well-defined lexical
definitions, darcs's "different files => trivial commute" would be
trivially extensible to "different defuns" by simply having "files" in
the repository be aggregate objects containing sequences of defuns
rather than blobs.
Does that buy us anything? I don't know yet. If it does, however,
Git is easily extensible to handle files as aggregates of defuns, and
(if your language is Lisp) defuns as aggregates of sexps, and so on.
Back to the patches themselves. As you've probably already
recognized, the patch I want to put in a blob is a primitive patch (a
hunk, TR, attribute change). In general patches will be aggregate
objects, containing other patches. However, this doesn't need to be
restricted to sequences of primitive patches. It doesn't even need to
be restricted to sequences of patches; you could have a whole version
tree encoded as an object. Since you would not have to carry the
content around with you, you could have a workspace which is aware of
the branch's context among other branches, even though it can't
actually be used to manipulate them.
Does this really buy us anything? I don't know yet.
I suspect that a few operations that are O(bytes) will become
O(top-level objects), which is likely to be more or less constant
("seven plus/minus two"), and enough to be worthwhile might become
O(objects) which seems likely to be O(log(bytes)).
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
_______________________________________________
darcs-users mailing list
[email protected]
http://www.abridgegame.org/mailman/listinfo/darcs-users
