Messages in this thread | | | Date | Sun, 16 Mar 2003 00:55:13 +0000 | From | Stig Brautaset <> | Subject | Re: [arch-users] Re: BitBucket: GPL-ed KitBeeper clone |
| |
On Mar 16 2003, Petr wrote: > > I think the arch-users@lists.fifthvision.net list would be happy to host > > continuing discussion in this vein. Considering Larry's repeated > > attempts to get people to look at arch as a "better fit," it seems > > particularly appropriate. > > > > Of course, you'd have to tolerate "arch community" views on a lot of > > these issues, but I suspect that might help focus the discussion. > > 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.
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/
| |