* Rob Weir:
>> The arch changeset format is rather strongly tied to arch semantics.
>
> Well, it's tied to a particular way of looking at changesets, yeah, and
> I'd be interested in what other semantics you'd like?
Special files are stored directly in the tree (mostly .arch-ids).
The namespace of intra-file IDs (arch-tag: lines in files) and
.arch-ids tags is separate. This might mean that this distinction
must be presevered even by non-arch users.
Binary files are not handled efficiently.
It's not possible to express most metadata used by other systems in
arch changesets.
Creation of arch changesets seems to require a working copy model
based on implicit tagging (at least for some project trees). Implicit
tagging seems to be unique to arch. A particular regular expression
library is required to create changesets (at least if you want to deal
with all ).
Other systems rely on fast application of changeset, and so far,
nobody has demonstrated that it's possible to write something that can
apply dozens of changesets per second, even for fairly small trees.
Some systems are not able to extract arch changesets as a file system
tree (because of path length issues or file name character set
problems).
There is virtually no documentation of the format, so it's hard to
tell what's an implementation artifact and what's a property of the
format itself.
>> This means that it doesn't handle copies, just renames, and you need
>> some kind of file ID. (You could tack copy support onto it, but you'd
>> lose arch compatibility to some extent.)
>
> Hm, what do you want copies to mean in the context of a changeset?
Well, something similar to a rename operation, but without the
deletion of the original file.
>> It's a binary format, and this is the real obstacle IMHO.
>
> Erm, no it's not. It's a directory structure, which is often tar'd and
> gzip'd.
I don't know of any human-readable serialization, the .tar.gz variant
is all we have at this point.
>> The curious result is that nobody actually sends arch changesets to
>> mailing lists, even though they are considered tremendously important
>> by the arch community.
>
> No, that the changesets are in seperate files is irrelevant. The
> essential point is that they are *conceptually* seperate; you can take
> one changeset out of a branch and apply it to others easily. You can
> serialise it, compose it, rip it apart and make new ones.
But this is not the way tla is usually used. tla lacks several
fundamental commands to construct changesets from named revisions. In
order to use the patch queue managers for tla that have been proposed
so far, you don't submit a changeset for application to some version,
but you provide a name of a revision to merge with. No changeset is
explicitly transferred, even in this case.
This is whayt I mean when I claim that arch changesets are actually an
implementation detail.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 10 20:15:04 2004