new batch of replies (A)

[Tom Lord]

Thanks to many of you for providing some challenging, interesting, and
useful comments and questions.  I have again coallesced replies.

In total, the replies are a bit over 700 lines long, so I've
broken them into four messages, and provided "tables of contents" to
make them easier to navigate.

A few of these questions gave me a great opporunity to explain some
difficult topics, such as why arch's merging facilities are valuable,
and how arch can help with process automation.

-t

Replies in this message:

	Mike Stump/Richard Kenner: A Merging Scenario
	Walter Landry: Arch is slow, slow, slow
	Walter Landry: Arch has Issues with Space v. Time Trade-offs
	Mike Stump/Zack Weinberg: IBM's System can do a Check-out in O(1) Time 

================================================================

* Mike Stump/Richard Kenner: A Merging Scenario

Great questions, by the way.


     Mike:

     You have a local change...  Someone else pounds in 100 changes to
     the base code, you merge up, the 100 changes go into your tree in
     one hunk, causing merging conflicts, rightly so.  If we take a
     step back (revert to pre-merge status), and then apply each one
     of the 100 changes, they all apply...

     [Richard (paraphrased): I don't see how one technique avoids
      conflicts while the other does not.]

`arch' has a quite complete selection of merging commands.

The `replay' command can be used to apply the 100 changes
individually.

The `update' command does the "all at once" style of merging.

The `delta-patch' command merges an arbitrary delta (taken between any
two revisions) to your tree.

The `star-merge' command does history-sensitive planning, figuring out
what combination of those other commands to use to perform a merge
between two branches that are merged back and forth periodically (as
between a development branch and a mainline).


	Also, the system should be able to take the base, pull out your
	changes, put in the 100 changes, then put your changes in...  Or a
	combination of the two, where the system combines both
	strategies.

`arch' supports this quite well, using the tools described above.


	All of this should be automatic and find the best solution
	first, and flexible enough to allow the user to say, I know
	you wanted to do it that way, but I want to do it this way.

One common case, the "star topology" case, is automated by
`star-merge'.  

Other cases are not automated in the sense that nothing looks through
the change sets, figuring out where conflicts are, and planning the
optimal patch application order.   I use a little trial and error
here, when it comes up.

I would like to add that, in arch, changeset logic (generation,
format, and application) are orthogonal to other concepts
(e.g. repository transactions).   So, if there is one of these
not-automated cases that comes up often for you, that would be a good
3-12 month project for an advanced student or junior engineer.  In
other words, the simplicity of arch and resulting tractability are
something to keep in mind.


	  The idea is to reduce the work the user has to do to resolve
	  conflicts.

Absolutely.  `arch' has all the low-level patching tools needed for
the tasks you've described, a little bit of high-level automation on
top of that, and is well positioned to add additional high-level
automation on demand.

An aside to Kenner: patching based on a cumulative diff of 100 changes
can create conflicts that won't occur if you apply the 100 changes
one-by-one.  Consider that Mike's pre-merge source contains regions:

	<unmodified region A>
	<modified region>
	<unmodified region B>

It is possible for the individual patches to separately change A and B
while the cumulative patch changes the union of all three regions.  In
that case, the modified region will cause a conflict that the
individual changes would not.  It is conceivable that we could tighten
up the definition of `diff' to prevent this problem: it's a research
question.


================================================================

* Walter Landry: Arch is slow, slow, slow


	Arch is slow, slow, slow.  Don't let Tom beguile you into
	thinking that it is even reasonably fast right now.  It isn't.

I'm not trying to beguile anyone.  Some important operations are
already quite fast, others are quite slow, the path to tuning where
needed is quite clear and easy.


================================================================

* Walter Landry: Arch has Issues with Space v. Time Trade-offs


       The problem comes when you want to get older revisions.  If
       you're at patch-51, getting patch-48 means starting from
       patch-0 and applying all 48 patches.  This can be sped up by
       saving entire trees along the way, but that kills the "highly
       compact format".

Arch offers a wide ranging and smooth selection of space-time
trade-offs.  Even at "near maximal space, near maximal speed", arch's
space requirements, while larger than CVS', are practical (nowadays)
for a project the scale of GCC.


================================================================

* Mike Stump/Zack Weinberg: IBM's System can do a Check-out in O(1) Time 

     Mike:

     One of your competitors (IBM) does [checkout] in O(1) time.  If
     you wonder what the constant is, oh, a few seconds.


Presumably using a (currently) non-portable file system trick.

     Zack:

     Implementing an analogue to mountable views on top of one of the
     new free-software version control systems would be an interesting
     project, IMO.  This would be quite easy to do on top of
     Subversion, since it implements (part of) the WebDAV spec; not
     sure about the others.

One of arch's options for trading storage space for time is called a
"revision library".  In that format, revisions are made available
locally as ordinary directories, with files unmodified between
revisions shared using hard links.

Given that primitive, serving those files via any network protocol
should be simple.

Locally, if you have directory stacks with COW capability, you can do
"O(1) checkout" using that facility.   Indeed, that facility can also
lower the storage requirements for revision libraries, though at this
time, since that facility is non-portable, nobody is working on it.