Your proposal is an interesting way of having two version
control systems "scratch each other's backs": Arch needs a
cross-platform repository storage mechanism, and Subversion
needs a structure/system for managing and distributing
changesets.
Svn brings a lot more to the table than "cross platform". For
example, you get very fast server-provided access to individual files
(which arch can do pretty trivially with a server-side "revision
library" -- but svn offers (at least potentially) better disk-space
usage via delta-compression. Another example is that in the arch
world, multi-revision client-side whole-tree caching is critical to
performance and svn offers an interesting mechanism. Another example
is the blend of CVS-style and changeset-style project mgt. I was
hinting about. People in arch-world not-infrequently talk about the
benefits of moving to "smart repositories" (in contrast to "brute
force repositories") -- as a design principle, I think it's critical
for arch not to rely on them but also that it's critical for arch to
be able to utilize smart repositories very well.
Arch brings in more than structure and distributing changesets, too --
but I'm not here to brag.
I kind of ragged (judging by the non-response to what was intended to
be a non-ragging question) on "someone" (sorry, I'm bad with names)
about a paper that drew a big distinction between CVS-style project
mgt. and linux kernel style project mgt. I don't think there's
really much distinction there other than scale. In that context,
my take on arch-from-svn-perspective -- that it can fill out the
core svn functionality by adding additional structure that supports
scaling (e.g. distribution) -- make sense (at least to me).
> Another weirdness has to do with modifying those patch-N
> trees. From the "pure arch" perspective, they are each
> "write once" entities. But now svn opens up a new
> possibility. Specifically, I can create "patch-N" but not
> mark it as "final" --- while it isn't "final",
> "patch-(N+1)" can't yet be created.
You're making my head spin! This is like double version
control.
I'd say more like version control at multiple scales. Or, "scalable
version control".
The collection of patches is one form of history,
but now the patches *themselves* have history as well?
Right. It's recursive. You have "bigger" changesets which are the
unit of sharing across distributed efforts; and "smaller" changesets
that constitute the development history of each of those "bigger"
changesets. One scale is of interest to one team (or from one
perspective); the other to another. (N.B.: "versioned changesets" is
a buzzword in the discussion on arch-users with lkml folks -- but the
stuff we're talking about here is an interesting subset of what that
buzzword refers to.)
So, I'm not sure what to do here. Whine, whine: I'm out of cash and
basic household infrastructure within hours-to-days at the moment
.... yet on the technical front, at least, I think we have more to
talk about. Anticipating and even sympathizing with groans from the
crowd, I'll mention that my paypal id is lord@emf.net. But I'll also
mention that more reasonably hacking around this particular financial
annoyance one way or another could be of mutual benefit.
"Inadvertent Amateur Busker",
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 3 01:02:29 2003