You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Marc Girod <gi...@stybba.ntc.nokia.com> on 2002/05/21 06:54:54 UTC
Build management (was: major design changes...can we)
Hello,
>>>>> "MCC" == Mark C Chu-Carroll <mc...@watson.ibm.com> writes:
MCC> PS: I suspect that it's probably time to move this discussion
MCC> off-list. If you'd like to talk more about it, I'll be glad to,
MCC> but I'm afraid
By no means!
I am currently trying to set up my mind about whether there is any
interest in subversion, after version 1.0.
And "any interest" means roughly derived object management via
auditing (such as build management, but probably generalized).
The rationale in short:
- Configuration items are members of a set, with an exclusion rule --
at most one member of every set in any configuration.
- Derived objects are the general case of configuration items;
versioned elements the exception.
To see why, take the tree metaphor: the amount of leaves grows in r
to the power of 2; the inside, to the power of 3.
I believe nobody should care for yet another RCS. However smart.
--
Marc Girod P.O. Box 323 Voice: +358-71 80 25581
Nokia NBI 00045 NOKIA Group Mobile: +358-50 38 78415
Takomo 1 / 1c47 Finland Fax: +358-71 80 61604
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Build management (was: major design changes...can we)
Posted by Sander Striker <st...@apache.org>.
> From: Greg Hudson [mailto:ghudson@MIT.EDU]
> Sent: 22 May 2002 16:40
> So far, the main justification I've seen for build management in a
> version control system is: if a project is (1) large, (2) rapidly
> changing, and (3) not compartmentalized, then builds take too long, so
> testing is sacrificed.
>
> Here's why I don't find that argument compelling:
>
> * The vast majority of projects are either not large, not rapidly
> changing, or are easily compartmentalized.
>
> * The particular problem can be solved independently of the version
> control system. (And I believe it has, in the form of caching compiler
> tools, though I can't find a pointer at the moment.)
http://ccache.samba.org/ for example.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Build management (was: major design changes...can we)
Posted by Greg Hudson <gh...@MIT.EDU>.
So far, the main justification I've seen for build management in a
version control system is: if a project is (1) large, (2) rapidly
changing, and (3) not compartmentalized, then builds take too long, so
testing is sacrificed.
Here's why I don't find that argument compelling:
* The vast majority of projects are either not large, not rapidly
changing, or are easily compartmentalized.
* The particular problem can be solved independently of the version
control system. (And I believe it has, in the form of caching compiler
tools, though I can't find a pointer at the moment.)
* The cost of integrating this functionality deeply into a version
control system is that people have to (or may believe that they have to)
adopt your build tools as well as your version control system.
Version control systems have had more penetration than general
configuration management tools. The general problem is hard, and even
if you solve it, your potential users won't understand what your product
does and will be resistant to adopting all of the necessary changes in
work habits at once.
On Tue, 2002-05-21 at 02:54, Marc Girod wrote:
> - Derived objects are the general case of configuration items;
> versioned elements the exception.
> To see why, take the tree metaphor: the amount of leaves grows in r
> to the power of 2; the inside, to the power of 3.
Eh? An n-level complete binary tree has 2^n leaves and 2^n-1 interior
nodes. And I'm not sure why the tree metaphor is apt; it doesn't
correspond to the usual relationship of source and derived objects in a
project. (Though, in most projects I've seen, the number of derived
objects is roughly the same as the number of source objects, same as a
tree.)
(Maybe you were talking about a real-life tree? Then your statement is
true, but it still doesn't seem to have much to do with projects.)
> I believe nobody should care for yet another RCS. However smart.
Reductionist, unjustified, and manifestly contrary to reality.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN != CVS++ was: Re: Build management
Posted by Greg Stein <gs...@lyra.org>.
Heh. When I said, "we're writing a CVS replacment", I didn't mean that we
were *simply* replacing CVS. That statement is not limiting in any way. You
can replace a 1947 Ford with a 2002 Corvette. Darn small minds :-)
My statement was more like: "we're writing a CVS replacment [that kicks its
ass from here till next Tuesday]"
That said, I'll endeavor to be clearer next time so that people won't
miscontrue what I mean. Let's see... maybe something like "we're writing a
kickass version control system to give the big smackdown to CVS".
[ and no... we're still not writing a build management tool *at this time* ]
Cheers,
-g
On Tue, May 21, 2002 at 03:59:45PM -0700, Justin Erenkrantz wrote:
> On Tue, May 21, 2002 at 03:38:15PM -0700, Brian Behlendorf wrote:
> > Actually, I cringe when I hear people say that. :) So many people wrote
> > off CVS for "real" SCM work because of problems with it that we're fixing
> > (I won't give the obvious list). So when those people hear "we're
> > rewriting CVS", they might perceive that as a strong reason to ignore SVN
> > now as well as down the road. So I think we're significantly
> > shortchanging SVN when we say it's a "CVS replacement".
>
> I agree with Brian here. I've talked to some people here at ICSE
> (IEEE Conf. on Sw. Eng. where I am this week). It seems that some
> people in SCM are proposing new versioning solutions because "CVS
> isn't good enough" and, dismissing SVN because after all, "SVN is
> just CVS++." I think that's a misconception we have to fight. A
> lot of the obstacles that prevents usage of CVS in research work
> have been fixed (IMHO) in SVN (extensibility is a real good place
> to start).
>
> I'll try to go to the SCM impact presentation on Friday to see what
> the eggheads are talking about. I doubt there'll be anything of
> interest to SVN, but you never know. Like Fitz, I'll try to
> evangelize SVN where I can. -- justin
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
SVN != CVS++ was: Re: Build management
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, May 21, 2002 at 03:38:15PM -0700, Brian Behlendorf wrote:
> Actually, I cringe when I hear people say that. :) So many people wrote
> off CVS for "real" SCM work because of problems with it that we're fixing
> (I won't give the obvious list). So when those people hear "we're
> rewriting CVS", they might perceive that as a strong reason to ignore SVN
> now as well as down the road. So I think we're significantly
> shortchanging SVN when we say it's a "CVS replacement".
I agree with Brian here. I've talked to some people here at ICSE
(IEEE Conf. on Sw. Eng. where I am this week). It seems that some
people in SCM are proposing new versioning solutions because "CVS
isn't good enough" and, dismissing SVN because after all, "SVN is
just CVS++." I think that's a misconception we have to fight. A
lot of the obstacles that prevents usage of CVS in research work
have been fixed (IMHO) in SVN (extensibility is a real good place
to start).
I'll try to go to the SCM impact presentation on Friday to see what
the eggheads are talking about. I doubt there'll be anything of
interest to SVN, but you never know. Like Fitz, I'll try to
evangelize SVN where I can. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Build management (was: major design changes...can we)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> Yes. People can say, "Subversion should do <this> or do <that>," but I'll
> always respond with "provide code" :-) Short of that, we're building a CVS
> replacement.
Oh wow, +1 all over what he said :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Build management (was: major design changes...can we)
Posted by Brian Behlendorf <br...@collab.net>.
On Tue, 21 May 2002, Greg Stein wrote:
> Yes. People can say, "Subversion should do <this> or do <that>," but I'll
> always respond with "provide code" :-) Short of that, we're building a CVS
> replacement.
Actually, I cringe when I hear people say that. :) So many people wrote
off CVS for "real" SCM work because of problems with it that we're fixing
(I won't give the obvious list). So when those people hear "we're
rewriting CVS", they might perceive that as a strong reason to ignore SVN
now as well as down the road. So I think we're significantly
shortchanging SVN when we say it's a "CVS replacement".
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Build management (was: major design changes...can we)
Posted by Barry Scott <ba...@ntlworld.com>.
It would worry me if the SVN versioning system had all the build objects
and other higher level features put in it.
With SVN's design it's easy to build the higher level tools.
What should be happening is people setting up projects to exploit
SVN as a great base.
Its what I plan to do. We have our own custom build processes that
I want to migrate off of SourceSafe and on to SVN. THe last thing I
need is misdirected efforts to add a build system within SVN that I
then have to defeat.
BArry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Build management (was: major design changes...can we)
Posted by Greg Stein <gs...@lyra.org>.
Alan: great post. To some extent, my response is just a "me too" :-)
On Tue, May 21, 2002 at 09:22:54AM -0400, Alan Langford wrote:
> At 2002/05/21 09:54 +0300, Marc Girod wrote:
> >I believe nobody should care for yet another RCS. However smart.
>
> If the architecture crafted sufficiently well, should it not be possible to
> provide a layer that provides a "filesystem front-end" interface to
> Subversion? Then someone who wants to craft a ClearCase calibre build
> system on top of that is free to do so.
You betcha. And I totally believe that Subversion is built to do so. Our
libraries are a big win here. I've envisione quite a few apps that can be
built on top of SVN. I might even say some are "way cool" :-)
> Either way, a good, robust and complete version management system is an
> essential component of a much wider variety of downstream applications.
> Tightly integrated build management isn't all that useful if you're trying
> to get control of a sales team's proliferation of PowerPoint presentations.
> Most of the interface to a friendly sales-document management system will
> be useless for build management. But if both of those systems run off a
> single version control technology, it's a huge win for the people who have
> to maintain and support them.
I *completely* agree. Consider a web-based doc mgmt system. Hey! It gets to
use the same repository as what the developers are using. Oh, and the techie
developers can use 'svn co' to access the docs rather than that "slow-assed
web site the services guys put together" :-)
> Subversion's mission, as I see it, is to fix the things that are wrong with
> (or even irritating about) CVS (which implies some additional
> functionality). Period. End. Anyone on this list probably agrees that's a
> big enough job as it is.
You bet. "Can we replace CVS yet? Yes? Ship it." We can then start having a
lot of fun after that.
> The open development process makes the odds that
> Subversion will be structured so that it's useful as a base for more
> sophisticated tools (after all, if it isn't, then just restructure it so it
> is ;) ). If you want a killer build management tool with a robust, widely
> supported back end, start designing.
Yes. People can say, "Subversion should do <this> or do <that>," but I'll
always respond with "provide code" :-) Short of that, we're building a CVS
replacement.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Build management
Posted by Alan Langford <ja...@ambitonline.com>.
At 2002/05/22 14:57 +0300, Marc Girod wrote:
> >>>>> "AL" == Alan Langford <ja...@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
>purpose.
>
>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
domains.
>- 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
Re: Build management
Posted by Marc Girod <gi...@stybba.ntc.nokia.com>.
Hello again,
>>>>> "AL" == Alan Langford <ja...@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
purpose.
In order to build some sophisticated "build management", one needs to
have local repositories (virtual file systems).
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?
--
Marc Girod P.O. Box 323 Voice: +358-71 80 25581
Nokia NBI 00045 NOKIA Group Mobile: +358-50 38 78415
Takomo 1 / 1c47 Finland Fax: +358-71 80 61604
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Build management
Posted by Marc Girod <gi...@stybba.ntc.nokia.com>.
Hi,
>>>>> "AL" == Alan Langford <ja...@ambitonline.com> writes:
AL> If you want a killer build management tool with a robust, widely
AL> supported back end, start designing.
Right. I know. This is the rule of the game.
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?
Before I would jump into such a huge investment, I'd rather make sure
sure there is a community to join. In fact, there is an annoying lack
of "continuity" that would typically prevent this kind of contribution
(not just "scratching one's itch").
And of course, nothing says I'd have either the skills or the time.
AL> Tightly integrated build management isn't all that useful if
AL> you're trying to get control of a sales team's proliferation of
AL> PowerPoint presentations.
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.
- 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.
--
Marc Girod P.O. Box 323 Voice: +358-71 80 25581
Nokia NBI 00045 NOKIA Group Mobile: +358-50 38 78415
Takomo 1 / 1c47 Finland Fax: +358-71 80 61604
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Build management (was: major design changes...can we)
Posted by Alan Langford <ja...@ambitonline.com>.
At 2002/05/21 09:54 +0300, Marc Girod wrote:
>I believe nobody should care for yet another RCS. However smart.
If the architecture crafted sufficiently well, should it not be possible to
provide a layer that provides a "filesystem front-end" interface to
Subversion? Then someone who wants to craft a ClearCase calibre build
system on top of that is free to do so.
Either way, a good, robust and complete version management system is an
essential component of a much wider variety of downstream applications.
Tightly integrated build management isn't all that useful if you're trying
to get control of a sales team's proliferation of PowerPoint presentations.
Most of the interface to a friendly sales-document management system will
be useless for build management. But if both of those systems run off a
single version control technology, it's a huge win for the people who have
to maintain and support them.
Subversion's mission, as I see it, is to fix the things that are wrong with
(or even irritating about) CVS (which implies some additional
functionality). Period. End. Anyone on this list probably agrees that's a
big enough job as it is. The open development process makes the odds that
Subversion will be structured so that it's useful as a base for more
sophisticated tools (after all, if it isn't, then just restructure it so it
is ;) ). If you want a killer build management tool with a robust, widely
supported back end, start designing.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org