On Sun, 16 Mar 2003, Petr Baudis wrote:
> I'm not sure if arch is the right thing to base on. Its concepts are surely
> interesting, however there are several problems (some of them may be
> subjective):
>
> * Terrible interface. Work with arch involves much more typing out of long
> commands (and sequences of these), subcommands and parameters to get
> functionality equivalent to the one provided much simpler by other SCMs. I see
> it is in sake of genericity and sometimes more sophisticated usage scheme, but
> I fear it can be PITA in practice for daily work.
>
> * Awful revision names (just unique ids format). Again, it involves much more
> typing and after some hours of work, the dashes will start to dance around and
> regroup at random places in front of your eyes. The concepts behind (like
> seamless division to multiple archives; I can't say I see sense in categories)
> are intriguing, but the result again doesn't seem very practical.
>
> * Evil directory naming. {arch} seems much more visible than CVS/ and SCCS/,
> particularly as it gets sorted as last in a directory, thus you see it at the
> bottom of ls output. Also it's a PITA with bash, as the stuff starting by '='
> (arch likes to spawn that as well) is. The files starting by '+' are problem
> for vi, which is kind of flaw when they are probably the only arch files
> dedicated for editting by user (they are supposed to contain log messages).
>
> * Cloud of shell scripts. It poses a lot of limitations which are pain to work
> around (including speed, two-fields version numbers [eek] and I can imagine
> several others; I'm not sure about these though, so I won't name further; you
> can possibly imagine something by yourself).
>
> * Absence of sufficient merging ability, at least impression I got from the
> documentation. Merging on the *.rej files level I cannot call sufficient ;-).
> Also, history is not preserved during merging, which is quite fatal. And it
> looks to me at least from the documentation that arch is still in the
> update-before-commit stage.
>
> * Absence of checkin/commit distinction. File revisions and changesets seem to
> be tied together, losing some of the cute flexibility BK has.
>
> I must have missed terribly something in the documentation given how arch is
> being recommended, please feel encouraged to correct me. But as I see it, most
I must have missed too. Last time I checked I had the same impression. A
bunch of shell scripts ( speed and portability goodbye ) and even
diff&patch were ran as external programs. Maybe it has the right concepts
but the architecture is *at least* weak. Subversion looked ( last time I
checked ) a better organized project, with *real* source code. Ok, it has
*insane* symbol names, but IMHO it's way better than the shell script
cloud.
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Mar 15 2003 - 22:00:44 EST