This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: source mgt. requirements solicitation



       > Also, the oft-repeated performance issues have kept me wary
       > about arch.

Fair if you're evaluating it from the "should I start using this
tomorrow" perspective (don't).

I think most of us who are fairly deep into arch think these problems
have straightforward solutions, and my goal is to try to find a
solution to the resource crisis that keeps me from finishing the work.

	 I realize that there are a lot of advantages to keeping to
	 high-level scripting languages for the SCM, but it's also
	 quite important to try to avoid making the SCM itself be a
	 distraction from a performance standpoint. However, since I
	 never got very far with arch, I really only parrot what I've
	 heard from others about its performance, so this may be
	 unfair.

The prototype/reference implementation of arch _is_ a mixture of shell
scripts and small C programs.  I think the enforced simplicity is very
good for the architecture and I'm quite optimistic about the future
performance potential of this code.

arch is tiny, and I'm encouraging alternative implementations for a
variety of purposes.  I hear that (have some salt grains with this)
someone is working on one in C++, and someone else on one in Python.
A Perl translation was made, but work on it seems to have stopped
(perhaps because the author changed work contexts) around the time it
was starting to function.

It is not quite accurate to say "the current implementation is slow
because it uses sh" -- some sh parts need recasting in C, many don't, 
some of the admin tweaks that improve performance need to be made more
automatic....things like that.   It's an optimizable prototype that
has not been prematurely optimized.

Just reading what you say here: the arch design has everything you
like about BK and probably a bit more to boot.  It's just a resource
problem to get it to a 1.0 that is as comfortable to adopt as you've
found BK.  Rumours that that will require $12M are exaggerated by, in
my estimate, about a factor of 10.

	To be honest, I tried arch back when I was testing different
	SCM's for the kernel, and even just the setup confused me
	enough that I never got past that phase. I suspect I just
	tried it too early in the development cycle, and that turned
	me off it.

Perhaps.  The currently active developers seem to be giving a lot of
attention to encapsulating matters such as that in convenience
commands layered over the core.


-t



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]