|
About:
arch is a modern replacement for CVS, specifically
designed for the distributed development needs of
open source projects. It has uniquely good support
for development on branches (especially good
merging tools), distributed repositories (every
developer can have branches in their own
repository), changeset-oriented project management
(arch commits changes to multiple files at once),
and, of course, file and directory renaming.
Release focus: Minor bugfixes
Changes:
Various bug fixes, documentation improvements,
and CLI improvements.
Author:
Tom Lord [contact developer]
Homepage:
http://www.gnu.org/software/gnu-arch
Tar/GZ:
ftp://ftp.gnu.org/gnu/gnu-arch/tla-1.3.tar.gz
CVS tree (cvsweb):
http://archzoom.sourcecontrol.net/[..]i/lord@emf.net--gnu-arch-2004/tla?expand
Mailing list archive:
http://savannah.gnu.org/mail/?group=gnu-arch
Trove categories:
[change]
Dependencies:
[change]
No dependencies filed
|
|
» Rating:
8.38/10.00
(Rank 333)
» Vitality: 0.01% (Rank 3307)
» Popularity: 4.91% (Rank 727)
 
(click to enlarge graphs)
Record hits: 37,415
URL hits: 21,110
Subscribers: 155
|
|
Branches
Releases
|
Version
|
Focus
|
Date
|
|
1.2.2rc2
|
Minor bugfixes |
19-Sep-2004 05:54 |
|
1.2.2rc1
|
Minor bugfixes |
09-Sep-2004 03:02 |
|
1.2pre3
|
Minor bugfixes |
23-Feb-2004 21:53 |
|
1.2pre2
|
Minor bugfixes |
28-Jan-2004 03:25 |
|
1.2pre0
|
Major feature enhancements |
29-Dec-2003 23:33 |
|
1.1pre9
|
Major feature enhancements |
26-Nov-2003 02:30 |
|
1.1pre7
|
Minor feature enhancements |
02-Oct-2003 20:37 |
|
1.1pre5
|
Major bugfixes |
01-Aug-2003 18:30 |
|
1.1pre4
|
Minor feature enhancements |
19-Jul-2003 06:30 |
|
1.1pre3
|
Minor bugfixes |
09-Jul-2003 08:17 |
Comments
[»]
It's time to move to arch and ofrget about CVS, bk and co
by Pau - Dec 16th 2003 14:00:21
arch is now not only the most flexible and distributed SCM system, but the
fastest and more space efficient too. You'll use only a fraction of the
space you need with other tools but without lose of speed ;)
Come on what are you waiting for?
--
linux 4u
[reply]
[top]
[»]
I'm not quite sure I buy that.
by Charles Duffy - Dec 16th 2003 22:29:54
> arch is now not only the most flexible
> and distributed SCM system, but the
> fastest and more space efficient too.
> You'll use only a fraction of the space
> you need with other tools but without
> lose of speed ;)
tla 1.1 is certainly much faster than prior versions of tla, and there are
many operations which it certainly does much faster than other tools. That
said, I'm not sure I'd agree to "fastest" without hard numbers including
comparisons of competitors (that is, svn and bk) -- and I certainly don't
agree with arch using a minimal amount of disk space, at least if one is
using a filesystem which penalizes having a large number of small files --
and if one has very large revision libraries (ie. the complete gcc tree
history), it's also for the better to be running a filesystem without a
fixed maximum inode count.
Keep in mind that many of Arch's design decisions emphasize robustness and
simplicity over localized "common-case" optimizations which make
presumptions about intended use-cases, with Tom's observations wrt how such
optimizations are inappropriate given the state of modern computing
hardware as the usual backing evidence. I certainly agree that this focus
is The Right Thing to do, but it also means that arch isn't really
optimized for tiny disk usage (at the expense of other things) in the same
way that some of competing systems are.
Observe recent posts on arch-users regarding the cumulative disk usage of
patch logs for an example of a case where arch uses more disk resources
than might otherwise be the case. Is it an appropriate design decision for
a modern revision control system, given the constraints within which it
was designed? Absolutely. Does it make arch an optimally space-efficient
revision control system? No, not really.
[reply]
[top]
[»]
Re: I'm not quite sure I buy that.
by Pau - Dec 17th 2003 00:18:42
>
> % arch is now not only the most
> flexible
> % and distributed SCM system, but the
> % fastest and more space efficient too.
> % You'll use only a fraction of the
> space
> % you need with other tools but without
> % lose of speed ;)
>
>
> tla 1.1 is certainly much faster than
> prior versions of tla, and there are
> many operations which it certainly does
> much faster than other tools. That said,
> I'm not sure I'd agree to "fastest"
> without hard numbers including
> comparisons of competitors (that is, svn
> and bk) --
In usual operations like get (checkout) and changes (diff -R), if you have
a working tree (a project) hardlinked to the previous revision, it's almost
impossible to be faster than arch. I don't say you can't be, but neither bk
nor svn architectures allow this kind of optimization. Even without
hardlinks, the inode signatures of each file allow for lightening
comparaisons. There's room for improvement in certain tagging methods like
explicit tagging, but the current status is certinly very competitive.
>
> and I certainly don't agree
> with arch using a minimal amount of disk
> space, at least if one is using a
> filesystem which penalizes having a
> large number of small files --
ext3 has these kind of problems with all the small files, this is not an
arch issue. I see a problem if you use explicit tagging because you double
the number of files (one file to store each id), but this is surmountable
and one of the points to improve during 1.2 development. I think the ext3
gourp is working in improving ths situation; BTW, reiserfs does not suffer
from it.
>
> and if
> one has very large revision libraries
> (ie. the complete gcc tree history),
> it's also for the better to be running a
> filesystem without a fixed maximum inode
>< count.
With the new sparse library revisions you do not need to keep all the
revisions in the library. That's a big win because you usually don't need
the ancient revisions but only the recent ones. Now it's up to you to
decide wich ones you do need. And if you choose it, whenever you need a
revision (i.e. to diff against), it will be automatically added. Moreover,
you can have libraires in multiple locations, a very useful feature when
you work in different devices or computers or when you want to share
libraries in a development group.
One more plus: with tla-1.1 you won't have more pristine trees (those are
full copies of a revision) that took a lot of space. They have been
replaced by spares revision libraries (these are the recommendations, in
fact they are there but I'm sure they'll dissappear in a couple of
releases). Revison libraries are much more useful because they are hard
linked among them (les space, more efficiency), and shared (pristines
belong to a working tree and, although you searched for them in the slibing
directories, taht was only a good hack now luckily overcome).
> Keep in mind that many of Arch's design
> decisions emphasize robustness and
> simplicity over localized "common-case"
> optimizations which make presumptions
> about intended use-cases, with Tom's
> observations wrt how such optimizations
> are inappropriate given the state of
> modern computing hardware as the usual
> backing evidence. I certainly agree that
> this focus is The Right Thing to do, but
> it also means that arch isn't really
> optimized for tiny disk usage (at the
> expense of other things) in the same way
> that some of competing systems are.
I don't agree with you in this point. Revisions are fully optimized caches
for revision control use. They are like working trees that share all the
not-changed inodes with the ancestor revision. You can even hardlink your
working tree to a cached revision, making it stil more effective. Caches
should improve speed and, in this case, they do it with the maximum
optimization.
The archive is not stored in a fully optimized binary format, but, as you
say, this is a good decision (ext3 will catch up some day). It allows to
have arch repositories withut special servers and retrieve the information
easyly if you wanted to ove to another system. A different backend server
(svn, for instance) could be plugged into arch withou a great pain, as
stated by Tom some times. The space trade off is worth the simplicity and
openness.
> Observe recent posts on arch-users
> regarding the cumulative disk usage of
> patch logs for an example of a case
> where arch uses more disk resources than
> might otherwise be the case. Is it an
> appropriate design decision for a modern
> revision control system, given the
> constraints within which it was
> designed? Absolutely. Does it make arch
> an optimally space-efficient revision
> control system? No, not really.
When you put a project under revision control, you should plan for a good
storage for the repository. If you have hundreds of changes, some space
will be used. There are tricks to cut those numbes down if you suffer from
that syndrome: recycle your archives from time to time, or create new
tagged branches, and store a cached revision in the archive so that you do
not need to keep the older pachlogs around. The solution is alredy there
and I doubt you can have the same kind of optimization with other SCM
tools.
--
linux 4u
[reply]
[top]
[»]
Re: I'm not quite sure I buy that.
by Charles Duffy - Dec 17th 2003 21:49:43
Pau,
I certainly agree that with advanced usage (such as trimming patch logs),
space-efficiency concerns wrt arch can be reduced. Whether it's the
application's fault or the filesystem's is irrelevant -- to a new user on a
common-case (ie. ext3) system who's accustomed to revision control systems
designed with space efficiency as a higher-priority goal than a
corruption-resistant repository format, arch *will* be relatively
space-inefficient. (Consider the following pathological case: in CVS, a
1-line patch means at most a few hundred bytes' increase to a preexisting
,v file; in arch, it's represented by at least two new files, each of which
the filesystem typically treats as at 4k in size).
Because of this, I'm uncomfortable with making space efficiency a selling
point to newbies -- because if they do a quick import of a typical CVS
project into arch (without bothering with the advanced-usage functionality)
and discover that it actually takes *more* space, then they're likely to
doubt the other, more defensible, claims made.
My issue here isn't that I think arch is a space hog -- far from it.
However, I think that it's a very dangerous proposition to promise
potential users that they'll use "only a fraction of the space" they're
accustomed to, when there are far more compelling elements to arch's value
proposition available.
[reply]
[top]
[»]
improving as good wine
by Pau - Nov 25th 2003 22:36:14
tla is geting better and better.
All the problems that arised to manage big source trees have been
addressed, usability issues solved, friendlyness of commands taken care
of... what else can I say, it's what you should be using to control your
software releases, mainly if you wnat a distributed model.
--
linux 4u
[reply]
[top]
[»]
it's lightening fast!
by Pau - Oct 2nd 2003 15:13:02
If you haven't tried it yet, go on! CVS and co are history.
--
linux 4u
[reply]
[top]
[»]
RIP CVS, long life to arch!
by Pau - Jun 26th 2003 04:35:47
If you use CVS and are fed up of its limitations, restrictions and annoying
workarounds, just bury it and use arch.
Things are damn easier to do, no need of central repository, complex
merges are done with just one instruction... too much to say in just one
comment.
Read the tutorial, try it and you'll see. And no, it's no Subversion, it's
much easier and, by now, powerful.
--
linux 4u
[reply]
[top]
|
