From: Jason McCarty <[EMAIL PROTECTED]>
Tom Lord wrote:
> Basically, the idea is that anyone can publish any commit they like by
> specifying a name for the commit, the names of immediate ancestors,
> and the contents of the tree --- the "snapshot" approach to revision
> control. Yes, I'm reversing my opinion of that approach from negative
> to favorable.
You had three questions:
[1] Can I ask why you've changed your mind?
[2] I haven't seen any reason why
this approach would be superior to treating changesets as the basic unit
of version control,
[3] or why it would be beneficial to layer arch on top
of git (or are these two questions unrelated?).
They're easiest to answer in the opposite order.
[3]: Layering Arch on top of a `git' is mostly an unrelated
question. One related question is whether or not to
compute tree and file checksums in exactly the same
way as `git', for interop purposes -- I don't have
a decision about that yet.
[2]: Storing snapshots doesn't preclude also storing
changesets and doesn't preclude using changesets
pretty much as Arch currently does -- the two
approaches can be reconciled.
[1]: I used to think that a snapshotting system could not be
written without sacrificing at least one of implementation
simplicity and overall functionality. (In other words,
I only saw how to build a simple but functionaly poor
snapshot-oriented system or how to build a functionaly
rich but very complex system.)
`git', `Mono', `Bazaar', and Aaron's work on revision-building
technology and caching contain many good ideas and
they have changed my mind about the feasability of a
snapshot-oriented system that is both very simple and
very powerful.
-t
_______________________________________________
Gnu-arch-users mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnu-arch-users
GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/
