Source code control

[Eric W. Biederman]

ron minnich <rminnich at lanl.gov> writes:

> one thing I don't much like are packages that require users to get a bunch 
> of software and load it before they can get the package. I like to 
> minimize barriers to entry, and we probably have all seen situations where 
> to get package Y, you need to get package X, which doesn't work on your 
> system Z due to conflicts with language/compiler A, B, and C. 
> 
> darcs requires people to get a Haskell and build it. Not so sure I like 
> this.
> 
> arch is a single C program but if we are really proposing changes I'd 
> rather not end up with maintaining an RCS as part of the project, so I 
> think the changes should go back into arch if they're really needed. 

Agreed.  Arch is at the maturity level now that it should be usable.
But at the same time I expect a few tweaks along the edges would be
nice.  Have you seen me work on a project make changes and not push
it back to the original developers?  And a big part of what
a distributed version control system does it that it makes this
easier.
 
> In the end, what does arch do better than bitkeeper? 

- Merging, arch has several methods.
- Branches, with arch you don't need multiple copies of your archive.
- The License.  The free Bk license requires at least your change
  history to be released, which for early development can trivially
  violate NDAs, which is a big concern on the LinuxBIOS side.
  The free Bk license forbids working on competitors to bk.
- Distribution.  All you have to do to export an arch repository for
  all the world to see is to point an ftp or http server at it's
  directory.
- Renames.  Since arch does not revision control the files individual
  but a change at a time you don't get into awkward situations with
  the SCCS version control file named differently than the file itself.

> I'd like to 
> understand that. bk is used for the Linux kernel itself, as well as the 
> infiniband source tree, which indicates to me that it is fairly robust. bk 
> has the same problem as darcs and arch, however: users will need to get 
> these and get them working before they can get etherboot/linuxbios.

Partly that is what releases are for, and we need to make those on the
LinuxBIOS side.  The only arch dependencies are diff, patch, tar, and
C.  And there should be prebuilt packages along shortly.

As for the Linux kernel half the developers don't use bk for
lots of things including at the moment Andrew Morton the 2.6
maintainer.  Getting arch to the point where the majority
of the kernel developers can use it productively is likely
what will require the most development effort at this point.

But it is possible at this point with almost no knowledge of arch
to take a raw repository to extract your changes with patch and tar.

> The 
> infiniband project fixed this by exporting to sourceforge. But sourceforge 
> was failing again for me today, so depending on that seems a
> mistake. 

Yay they responded to my complaints. :)  

Also there is also a different level of care you need to give to an
open source tool and a tool with a more restrictive license.  With a
more restrictive license, some people will never use the tool.  With
an open source tool the only concern is the tool painful to setup.

> The 'arch' web pages have a few 'we need help' items, which leaves me
> somewhat concerned.

arch is maturing quickly and has an active developer community.  With
tla 1.1 out arch does not appear to be lacking anything significant.  
The core looks fairly solid but arch is not so old there still won't
be itches to scratch.

I am in the middle of a fairly in depth technical review.  And I am
going to make darn certain there we need missing before I seriously
suggest switching over.  I have what two sets of criteria I am using
to evaluate arch, immediate needs, and expected long term needs.  So
far I have seen nothing in the immediate needs category missing.  For
the long term needs I have seen a few possibilities.

The best analogy I can think of is cluster applications like mpi.  It
is trivial to scale to 20 or 30 nodes.  Getting an implementation that
works and scales to the 1000s of nodes is a bit more work, even when
there is a good design that support it.  There are always issues at
the large scale you can't see at the small scale.

Arch is that way right now.  The design looks good. It runs fine on
small projects but it has not been pushed to the large scales yet.

> Is the motivation here perceived problems with CVS (not hard to imagine) 
> or with sourceforge (also not hard to imagine).

CVS, sourceforge, and the fact that there are currently at least
4 repositories for the freebios2 tree alone.  And for LinuxBIOS that
inherently makes sense.  With a distributed source code control system
we can continue working the way we are working now and have the tools
to merge the repositories.

Basically with a distributed version control system everybody and
their brother can have commit access.  They just can't commit to
the official branch.  

On the etherboot side the only real problem I have is by checking
in the repository multiple times getting code from one repository
to another is a pain.  As evidenced by the fact that EFI support
still has not made it into the 5.2 and 5.3 branches yet...

Eric