Someone made a script not long ago to create four-letter aliases of all
arch commands. Instead of `larch star-merge' you type `lstm'. Does that
sound more like what you want?
> * 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.
Chose shorter names ;p
> * 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.
echo "alias ls='ls --ignore {arch}'" >> .bashrc
Funnily enough, {arch} lists _first_ in ls output here. That was the
idea behind the curly braces in the first place too afaik.
> Also it's a PITA with bash, as the stuff starting by '=' (arch likes
> to spawn that as well) is.
No it doesn't. Tom, the main author of arch, likes files starting with
`='. The rest of us are not so sure ;) Off the top of my head I cannot
think of any file users should have to touch wich have a name starting
with `='.
> 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).
This is a known issue and is being looked into afaik.
I for one agree completely with this point.
> * 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).
Arch being a bunch of shell scripts:
http://arch.fifthvision.net/bin/view/Main/ArchMyths
Three-fields version names is being worked at IIRC.
> Also, history is not preserved during merging, which is quite fatal.
Not true. Any merge will include patch logs for the merged-in patches.
> And it looks to me at least from the documentation that arch is still
> in the update-before-commit stage.
have you looked at the --out-of-date-ok flag to commit? (not that I
understand why you would want to use that...)
> rewritten sooner or later anyway. The backend history format doesn't appear to
> be particularily great as well. Dunno. What's so special about arch then?
This say it so much better than I can:
http://arch.fifthvision.net/bin/view/Main/WhyArch
Stig
-- brautaset.org - 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/