[SM-Discuss] SVN as p4 replacement
Seth Woolley
swoolley at panasas.com
Mon Mar 20 14:45:25 EST 2006
Sergey A. Lipnevich wrote:
> Seth Woolley wrote:
>
>>Sergey A. Lipnevich wrote:
>>
>>>Seth Woolley wrote:
>>>
>>>
>>>>P.S. I'll note that any split spells in general are a PITA because
>>>
>>>
>>>Subversion is not a split spell AFACT. What do you mean here :-)?
>>
>>Take a look at its dependencies.
>>
>
>
>
> Well, I created this spell, and I can tell you that it's not "split" in
> my book. Maybe we differ on what "split" means but then I'd assume
> spells like php and cyrus-sasl are also "split" because they have many
> dependencies. So I'm sorry to repeat the question, but what do you mean?
> Maybe it would help to post your compile log and subversion.p file first.
> Thanks,
By split I mean stuff that could be compiled with one spell are split
into multiple spells that need more enhanced relationships between them
than normal dependencies. I don't mean subversion is a split spell, but
its dependencies are complicated and have never reliably built for me
(then again, in testing, I always test from scratch so developers often
never see the failures I see first).
Things like apr|apr0 apr-util|apr0-util for example. It might not even
be related to this as it failed on a compile error I didn't take a look
into. In about five hours I'll have a chance to sit down and pull up
the compile logs. :) If I remember correctly the problem wasn't in
subversion itself, the dependencies failed for it long before it got to
subversion itself.
If there's a way, as mentioned previously, to not require anything
apache-related to build svn, I'd be greatly for that. It's not that
they are bad coders or anything like that -- they are just bad
architects for designing it the way they did. Fragility is never a good
mark of a well-architected system.
All I'm saying is that before we switch to anything, I'd like to know
that I can expect our own system to build it reliably in cases we care
about. This is currently not the case for subversion.
Seth
--
Seth Alan Woolley
Software Engineer
Accelerating Time to Results(TM) with Clustered Storage
www.panasas.com
swoolley at panasas.com
510-608-4382
More information about the SM-Discuss
mailing list