On Fri, Jan 25, 2002 at 12:41:31PM -0500, Greg Hudson wrote:
> I've thought about how to do a direct mapping to the filesystem, and I
> came up with a fairly simply idea: if REPOS is the path to the
> repository, then REPOS/1 is the first revision, REPOS/2 is the second
> revision, and so on. Inside a revision, you can have a relative
> symlink back to a previous revision for an unchanged file or
> directory. Files can contain raw contents or diffs against some other
> path. When you're doing a commit, you build up a new rev in
> REPOS/some-id-string, and when you're ready to finalize the commit you
> merge it with any commits which have been made in the meantime and
> then rename it to REPOS/3 or whatever the next number is.
For whole tree revisions, that sounds like a very interesting
system. Not what I was thinking, but interesting anyway. :-)
> Anyway, I'm not sure you've learned yet how Subversion does tags and
> branches. Subversion just provides cheap directory copies; it doesn't
> have a namespace for tags and branches separate from the regular
> repository namespace.
I've been trying to figure it out, and it's quite confusing. If
someone would write up a sample branch, develop and merge scenario,
elucidating how the tree version numbers change for branch and trunk
commits, I think I'd be much wiser.
> I think the Subversion method of doing branches and tags is... bold, but
> worth experimenting with. It actually flows out of your arguments about
> having a single namespace.
Hmmm...
What about if you want version x of most of the tree to be part
of a particular revision, but version y of a particular subsystem?
Would you have to create a branch in which that was the case for it to
work that way?
> I don't like it either. The application protocol world has been pulled
> in two directions recently: one contingent wants to design the simplest
> possible protocols from a birds-eye view, and the other contingent wants
> to reuse protocol components--even if they are bulky, flawed, and full
> of unneeded features--in order to reduce development time, get some
> forms of compatibility between protocols, and in some cases to get
> through firewalls. (Although, never bring up that last argument in an
> IETF context; the IESG believes, probably correctly, that it's unethical
> to deliberately subvert firewall policies by running a new protocol on
> the same port as an existing protocol.)
One of the biggest problems I see in bulky application protocols
is a pernicious assumption of synchronous behavior on the part of one
party or another. Even chips are going to move to be asynchronous
because light is too slow for all the components in a whole square
centimeter to all agree on a state to be in and still be fast.
> I'm in the first camp, but it's hard to counter the arguments of the
> second camp, and in my experience they generally win any time a system
> is designed by a heterogeneous committee.
If there were any upper layer protocols I thought were worth
anything, I might be in the second camp. For example, hardly anybody
disagrees on using TCP/IP for most things, for good reason.
Have fun (if at all possible),
--
"It does me no injury for my neighbor to say there are twenty gods or no God.
It neither picks my pocket nor breaks my leg." --- Thomas Jefferson
"Go to Heaven for the climate, Hell for the company." -- Mark Twain
-- Eric Hopper (hopper_at_omnifarious.org http://www.omnifarious.org/~hopper) --
- application/pgp-signature attachment: stored
Received on Sat Oct 21 14:37:00 2006