This is just a heads up. I have been doing some investigation into distributed version control systems. arch looks like it usable and getting more usable.
From the design standpoint I don't see any big issues and
it appears to be the equal of bk etc. I think I see some was to make it simpler and more powerful but that is not needed to make a good revision control system.
I need to do a little more testing to see what arch is actually like to use. Before I seriously start advocating anything but I'm not expecting any weird issues to crop up. Except possibly for some issues running under cygwin, for the platform challenged.
Once my evaluation is finished I plan on pushing the projects I work on in that direction. So this is something to think about.
Eric
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.
In the end, what does arch do better than bitkeeper? 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. The infiniband project fixed this by exporting to sourceforge. But sourceforge was failing again for me today, so depending on that seems a mistake.
The 'arch' web pages have a few 'we need help' items, which leaves me somewhat concerned.
Is the motivation here perceived problems with CVS (not hard to imagine) or with sourceforge (also not hard to imagine).
ron
ron minnich rminnich@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
Eric, I just realized that since you contributed to 'arch' you are locked out of using bk!
OK, your point it well taken!
ron
Not to bang the BK drum, but I'd hate to see the arguments for or against it misrepresented.
On Mon, 2004-01-05 at 06:15, Eric W. Biederman wrote:
In the end, what does arch do better than bitkeeper?
- Merging, arch has several methods.
BK's merging support is, for what it's worth, by far the best I have seen. It does most merges automatically that tools like CVS just dump you into vi for.
- Branches, with arch you don't need multiple copies of your archive.
BK has pretty cheap branching support. It uses a tree of hardlinks if that's what you want, so you just end up paying in inodes.
- 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.
BK has a built-in server that provides the same facilities.
- 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.
BK supports renames and metadata changes (file modes, mostly) perfectly well.
BK is pretty slow on a large tree. However, it's several thousand (!) times faster than arch in most cases, which is by design just abominably slow at even the most trivial of common operations.
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.
One solid reason for this is that BK doesn't have good GNU patch handling support. You can import a GNU patch into BK, no problem, but it's a huge PITA to then manage successors to that patch as their maintainer issues them. You're basically left in manual merge hell.
Andrew wrote his own set of scripts, which have since taken on a life of their own, to handle a pile of patches against a tarball. This works better than BK for a loosely-coupled world in which everyone flings GNU patches around. If you have a tighter world in which 90% of people deal in terms of BK patches, BK is a lot easier to work with than the patch scripts.
On the other hand, there's a lot to be said for open source software in this realm. Larry is perfectly happy to tell paying customers to fuck off (and in approximately that language, too, as Ron can probably attest) if he doesn't want to implement a feature they're requesting. The flip side is that arch is about a decade away from being as performant and mature as BK is today.
<b
"Bryan O'Sullivan" bos@serpentine.com writes:
Not to bang the BK drum, but I'd hate to see the arguments for or against it misrepresented.
I agree that the way I stated the differences BK didn't sound too good.
On Mon, 2004-01-05 at 06:15, Eric W. Biederman wrote:
- 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.
BK has a built-in server that provides the same facilities.
Nice but not quite as convenient, as needing no special server. Sort of the plain text versus the binary file argument, until it is a performance bottleneck the extra convenience has a lot of nice secondary side effects.
BK is pretty slow on a large tree. However, it's several thousand (!) times faster than arch in most cases, which is by design just abominably slow at even the most trivial of common operations.
That arch is slow is something I will look into. Although it should be able to trivially be beat sourceforges anonymous CVS servers...
On the other hand, there's a lot to be said for open source software in this realm.
Right.
The flip side is that arch is about a decade away from being as performant and mature as BK is today.
If the performance is not good enough to be usable we won't go there. And if it is usable but annoying it can be fixed.
Eric
* Eric W. Biederman ebiederman@lnxi.com [040105 23:17]:
BK is pretty slow on a large tree. However, it's several thousand (!) times faster than arch in most cases, which is by design just abominably slow at even the most trivial of common operations.
That arch is slow is something I will look into. Although it should be able to trivially be beat sourceforges anonymous CVS servers...
This is something that has pretty much changed when arch was rewritten from being a big huge mess of shell scripts to one single binary called tla. The former was pretty unusable, the later works not (noticably) slower than bk.
The flip side is that arch is about a decade away from being as performant and mature as BK is today.
If the performance is not good enough to be usable we won't go there. And if it is usable but annoying it can be fixed.
bk has some nice gui tools that I really miss from tla. Last time I checked tlator, it was really more a try than a program... On the other hand that is just my i-need-colors-to-go-away-from-cvs attitude...
For the merge facilities, I don't think this project has had, or will have, big problems with merging different trees together. And no versioning system can make up to the caution it takes to see the conceptional problems that might hide behind a merge conflict.
Stefan
I am reforwarding this as it got dropped by a bunch of 'naughty language' filters ...
ron
On Mon, 5 Jan 2004, Bryan O'Sullivan wrote:
Not to bang the BK drum, but I'd hate to see the arguments for or against it misrepresented.
On Mon, 2004-01-05 at 06:15, Eric W. Biederman wrote:
In the end, what does arch do better than bitkeeper?
- Merging, arch has several methods.
BK's merging support is, for what it's worth, by far the best I have seen. It does most merges automatically that tools like CVS just dump you into vi for.
- Branches, with arch you don't need multiple copies of your archive.
BK has pretty cheap branching support. It uses a tree of hardlinks if that's what you want, so you just end up paying in inodes.
- 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.
BK has a built-in server that provides the same facilities.
- 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.
BK supports renames and metadata changes (file modes, mostly) perfectly well.
BK is pretty slow on a large tree. However, it's several thousand (!) times faster than arch in most cases, which is by design just abominably slow at even the most trivial of common operations.
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.
One solid reason for this is that BK doesn't have good GNU patch handling support. You can import a GNU patch into BK, no problem, but it's a huge PITA to then manage successors to that patch as their maintainer issues them. You're basically left in manual merge hell.
Andrew wrote his own set of scripts, which have since taken on a life of their own, to handle a pile of patches against a tarball. This works better than BK for a loosely-coupled world in which everyone flings GNU patches around. If you have a tighter world in which 90% of people deal in terms of BK patches, BK is a lot easier to work with than the patch scripts.
On the other hand, there's a lot to be said for open source software in this realm. Larry is perfectly happy to tell paying customers to f@@@ off (and in approximately that language, too, as Ron can probably attest) if he doesn't want to implement a feature they're requesting. The flip side is that arch is about a decade away from being as performant and mature as BK is today.
<b
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Etherboot-developers mailing list Etherboot-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/etherboot-developers
-
Bryan O'Sullivan -
ebiederman＠lnxi.com -
ron minnich -
Stefan Reinauer