[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Build management

From: Alan Langford <jal_at_ambitonline.com>
Date: 2002-05-22 18:30:59 CEST

At 2002/05/22 14:57 +0300, Marc Girod wrote:
> >>>>> "AL" == Alan Langford <jal@ambitonline.com> writes:
>AL> If the architecture crafted sufficiently well, should it not be
>AL> possible to provide a layer that provides a "filesystem front-end"
>AL> interface to Subversion?
>One more comment / question, which I made actually already in my reply
>to Noel Grandin two days ago: it is not so much a question that the
>architecture would be crafted *well* enough, but suitably for the
>In order to build some sophisticated "build management", one needs to
>have local repositories (virtual file systems).

Let me rephrase. "Well enough to easily accommodate an interface that makes
it function as a local filesystem."

>If I got it right, this differs from the model currently retained in
>subversion for multi-site support, which is based on remote access to
>a shared repository.
>So, did I get it right?

I'm neither working on the code nor sufficiently familiar with the code
base to provide a clear answer. However you can be certain that a local
repository is a possibility; there has also been discussion of the desire
for a non-web-based interface, but I'm not sure how actively this is being
pursued pre-1.0; Certainly there's a "server-side" API that could be used
as the back end for a virtual file system front end, allowing you to build
a strictly local solution.

>Now tell me why should I do it _on top of subversion_? And e.g. not on
>arch, katie, Elephant File System, CVFS, Moraine or whatever, or even
>from scratch?

 From scratch is the easiest to address: because it's a complex problem to
do right, so if someone has already done it right, you can gain far more by
using that as a base. IMO one reading of the archives of this list should
terrify any rational human being into leveraging the investment.

 From there, the choice of underlying RCS is a matter of taste and personal
judgement. Evaluate the tools, the calibre of the code base, the size and
spirit of the community, the programming language... and then decide which
(if any) of the environments gives you the greatest leverage for getting
the results you want. Maybe this means you create Yet Another Revision
Control System on tigris or sourcefourge, maybe it means you build The Best
Tool Ever in your basement. Maybe it means you purchase a commercial solution.

>And of course, nothing says I'd have either the skills or the time.

Then hang out on the list and make suggestions when you can... That's all
I've been doing; hoping one of my ramblings will be useful.

>Two answers to that:
>- I think you are fooled by the words "build management", which are
> only an accident of history. What is at stake might be as wide as
> dependency auditing, or generic (and thus partial) structuring of
> information.

Let me make the statement more abstract. A versioning engine is a basic
component of a number of solutions. Some aspects of a solution in one
problem domain are likely to be orthogonal to aspects in another domain.
Therefore, it's a Good Thing to construct that base component in a robust,
flexible way that allows it's application into the broadest range of target

>- One shouldn't try to fight people willing to avoid collaboration.
> Producing PowerPoint slides is a choice: creating artifacts instead
> of maintaining information. The motivation is partly romantic, and
> driven by metaphors of the past: the individual artist, general or
> hero.

You are obviously unfamiliar with this problem domain. Try wrestling with a
few gigabytes of presentations from just a few reps, each of which is in
some way slightly derivative of a random predecessor, with the intent of
adding a new product to what should have been a standard slide. Watch as
you discover that you lost the business with Oracle because the rep based
his presentation on something that touted your close relationship with
Microsoft, and he was too rushed to too clueless to fix it.

There are some places where free artistic expression is inappropriate. In
this case the challenge is to allow some freedom without having the risk
that your CEO's keynote presentation at Comdex will contain a nude of the
sales manager's girlfriend. Or at least to have an audit trail that allows
you to discipline the appropriate moron.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 22 18:32:19 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.