binary searching CVS, automation, arch news

[Tom Lord]

a) Binary searching through CVS revisions using _dates_ is
   only an approximation of what you really intend to do.
   You'll have a hard time, with such a search, getting a 
   tree for the point between two commits close in time.
   If there are commits that span the time coordinates that
   your search probes, you'll be testing trees that contain
   just part of those commits (and that are likely useless
   as a result).   So, here, you'd be better off using any
   modern system that features atomic multi-file commits.

   In arch, successive revisions are assigned sequential numbers,
   so your binary search can use simple arithmetic on those
   revision numbers to select points in the history to test
   (no fussing with dates, for example, and no need for tricky
   queries to find the list of revisions that effect the branch
   you are testing).


b) Robert Dewar says (of automated acceptance testing):

	Yes, indeed, automating requirements like this is always
	desirable. Although you probably want ways to override
	requirements in emergencies.

	What we find is that the key point is that it must be *easy*
	to follow procedures, if it is, then they get followed, if
	not, no amount of social pressure can guarantee conformance
	:-)

   Let me just say in response that, if arch did become a funded
   project with a little team working on it, I'd want to see the
   effort have three mostly-concurrent parts:

	1) A "theory" part, concerned with developing and 
	   writing high quality formal specifications (e.g., 
	   for changeset syntax and semantics)

	2) An "implementation" part, concerned with verifying 
	   the reference implementation, keeping it up with the
	   specs, and performance tuning it.

	3) An "application" part, concerned with building a 
	   real-world infrastructure, using arch, for a large real-world
	   project.  We'd want to build this infrastructure "off-line"
  	   -- not even attempting to begin deployment in the target
	   project until the infrastructure was reasonably mature and
	   clearly an upgrade.  But we'd also want to (a) attempt to
	   track some development on the project -- to follow along
	   with it in parallel, and (b) engage the project's
	   developers to contribute design review and ideas for this
	   infrastructure as we go along (c) seek to deploy
	   incrementally, anticipating a period when some developers
	   adopt the new infrastructure while others stick with the
	   old, probably moving mainline and maintainer branches to
	   the new infrastructure later, rather than sooner.

	   I agree with generalities about "overrides" and making
	   things "*easy*" and (from other comments) "fast" -- it's
	   this application aspect of the project that can help make
	   those generalities specific.  If a project like this had
	   started six months ago, then when the recent need for a
	   binary search through revisions to isolate a bug came up,
	   maybe we could have done that -- even before deployment.


c) I often tout the small size and tractability of arch as one of its
   virtues.  Recent traffic on the arch developers list at
   www.fifthvision.net/Arch is entertaining in that regard.  While
   some developers have decided to start rewriting parts in C++,
   some current users object to that -- and boom, new forks have 
   already been announced over the issue.   That people consider
   making forks just for their own private deployment is, I think, 
   a testimony to arch's overall simplicity.


d) One user recently reported (and, sorry, I know there's not enough
   data in this anecdote to do envelope computations):

	I have then taken this archive and have converted it to Arch
	with an rlogparse.py and cvs2arch script I have put together
	that tracks the commits in the CVS archive and converts them
	to Arch prompting for user input when it comes to a tag/branch
	to see what the user wants to do with it on the Arch side.  I
	am talking over 10 years of data here converted consuming over
	500M of space once in Arch.  Not bad for a micro-kernel
	really.

   At least qualitatively, that suggests that even the prototype is 
   capable of some respectable feats.