You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@newton.ch.collab.net> on 2002/10/10 20:03:23 UTC
Re: collaborating
Tom Lord <lo...@regexps.com> writes:
> I propose an intense and focused goal and design review, and goal and
> design restatement, encompassing both of our projects, and looking
> beyond them to the other tools in a software engineering tool-chain. I
> think that now is a good time for us all to step back, take stock of
> what we have and what we need, and to make a solid plan for execution
> moving forward.
Ahhh. Okay, I see what you're driving at.
I agree with your observations about the scope of the general revision
control problem. But Subversion can't afford a drastic redesign. We
decided early on about the problem we were solving -- replacing CVS --
and the software is targeted squarely at that problem. I'm betting we
can add changeset functionality, but not via a complete redesign;
instead, we will have to find ways to do it incrementally, without
significantly delaying upcoming milestones. A complete rescoping at
this point would be insanity, from a project management point of view.
If you still think you can help, given the above, then great! But
we'll understand if you feel it's impossible.
Note, of course, that this isn't really about what Subversion can
withstand, it's about what people can withstand. I'm pretty sure the
current developers are in agreement that we're not going to rescope
now. So fine, this particular group of people is not prepared to
start redesigning Subversion. But if *you* think Subversion could be
redesigned to replace BitKeeper and still brought to a releaseable
state before the heat death of the universe, and you can find
developers who agree with you, go for it. I can't persuade myself
that it would work, so I'm not going to join that effort, however.
The recent BitKeeper license changes doesn't affect any of this, btw.
BitKeeper wasn't Free before, and it isn't Free now. So there's as
much need for a truly free tool that solves "The BitKeeper Problem"
today as there was yesterday. Maybe someday that tool will exist, and
maybe Arch or Subversion will be part of it.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: collaborating
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Zack Weinberg <za...@codesourcery.com> writes:
> > What Subversion 1.0 will be is pretty much nailed down, at this point.
> > And I think that 1.0 will be a valuable system on its own terms. Just
> > replacing CVS, without making all of these interesting process
> > improvements, is valuable for all the organizations out there running
> > into the design limitations of CVS - working on GCC, I struggle with
> > these every day.
>
> Thanks, Zack, that's a much better way to say it.
>
> I don't think we should do a stop-and-review before 1.0. We know
> where we're going and basically how to get there. But after 1.0 is
> out the door? Sure!...
Review of the existing goals and design in parallel with the 1.0
train of development with a target of 2.0 makes a lot of sense.
Even so, I'm waiting like a crouching tiger to jump on 1.0 final. I
certainly wouldn't want it delayed -- I echo the pained sentiments of
other CVS admins and users on this list. ;-)
--
Daniel Rall <dl...@finemaltcoding.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: collaborating
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Zack Weinberg <za...@codesourcery.com> writes:
> What Subversion 1.0 will be is pretty much nailed down, at this point.
> And I think that 1.0 will be a valuable system on its own terms. Just
> replacing CVS, without making all of these interesting process
> improvements, is valuable for all the organizations out there running
> into the design limitations of CVS - working on GCC, I struggle with
> these every day.
Thanks, Zack, that's a much better way to say it.
I don't think we should do a stop-and-review before 1.0. We know
where we're going and basically how to get there. But after 1.0 is
out the door? Sure!...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: collaborating
Posted by Zack Weinberg <za...@codesourcery.com>.
On Thu, Oct 10, 2002 at 03:03:23PM -0500, Karl Fogel wrote:
> Tom Lord <lo...@regexps.com> writes:
> > I propose an intense and focused goal and design review, and goal and
> > design restatement, encompassing both of our projects, and looking
> > beyond them to the other tools in a software engineering tool-chain. I
> > think that now is a good time for us all to step back, take stock of
> > what we have and what we need, and to make a solid plan for execution
> > moving forward.
>
> Ahhh. Okay, I see what you're driving at.
>
> I agree with your observations about the scope of the general revision
> control problem. But Subversion can't afford a drastic redesign. We
> decided early on about the problem we were solving -- replacing CVS --
> and the software is targeted squarely at that problem. I'm betting we
> can add changeset functionality, but not via a complete redesign;
> instead, we will have to find ways to do it incrementally, without
> significantly delaying upcoming milestones. A complete rescoping at
> this point would be insanity, from a project management point of view.
Let's rephrase the terms of the dialogue.
What Subversion 1.0 will be is pretty much nailed down, at this point.
And I think that 1.0 will be a valuable system on its own terms. Just
replacing CVS, without making all of these interesting process
improvements, is valuable for all the organizations out there running
into the design limitations of CVS - working on GCC, I struggle with
these every day.
But the Subversion project isn't going to fold up and vanish just
because 1.0 is out the door. There's tons of ideas that have shown up
and been relegated to "post 1.0" - well, now might be a good time to
start talking about the road map for 2.0, and specifically whether we
can fit some of Tom's ideas into Subversion in that time frame.
Incremental change is a good thing. Suppose we put Subversion 1.0 out
there with a clear migration path from CVS, and get uptake from major
free software development projects. There won't be any radical
process improvements like the ones Tom is suggesting, just from that.
But, suppose that some of Tom's ideas show up in Subversion 2.0 - then
the people out there who are using 1.0 will have a much easier
migration path to those new ideas, than if they were to have to jump
from CVS *and* from their old process at the same time.
I have a couple of specific comments on Tom's white paper which I will
put in a separate message.
zw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: collaborating
Posted by Dan Martinez <df...@area.com>.
Paul Lussier wrote:
> I know I'm new here, and am not a contributor in any sense, so I
> don't really have any say either, but isn't there a way that both
> could be accomplished?
>
> ...
>
> Does CVS really need replacing? It's hobbled along for so long that
> everyone using it is pretty comfortable with the way it works.
> Couldn't they survive until not only something better came along,
> but until the *best* something else came along?
I'm not a contributor either, but I *am* one of the people involved in
maintaining CVS at a reasonably-sized organization, and I can
categorically state that I am *not* "pretty comfortable" with the way
it works.
I can tolerate it, for the most part, but hardly a day passes that I
don't wish for something better. I can live with the fact that
branching and tagging take about fifteen minutes each, since it's only
my time that's being spent, but I feel vaguely dirty every time I have
to explain to a user that there's no sane way to rename a file, or
that directories aren't versioned at all.
Something that strongly resembles CVS while addressing its more
obvious shortcomings would be a great blessing, which is why I'm
eagerly looking forward to Subversion 1.0, as are about half the folks
I know.
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: collaborating
Posted by Blair Zajac <bl...@orcaware.com>.
"Glenn A. Thompson" wrote:
>
> >
> > I would also like to see a nice review of various SCM systems. Don't any of
> > the software dev mags have some articles like this? Google isn't turning up
> > much...
> >
>
> There was a guy who posted some questions for the team to answer. I thought he
> was writing an evaluation.
> What became of that?
> gat
I haven't seen it yet either and I put the answers together.
Alessandro,
What's the status of your magazine review?
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: collaborating
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
>
> I would also like to see a nice review of various SCM systems. Don't any of
> the software dev mags have some articles like this? Google isn't turning up
> much...
>
There was a guy who posted some questions for the team to answer. I thought he
was writing an evaluation.
What became of that?
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: collaborating
Posted by Ben Gollmer <be...@jatosoft.com>.
> If there is any *neutral* paper on the Net comparing CVS, SVN, Arch,
> BK and friends (foes?), it'd be really nice. If not, I might even be
> interested in writing one actually, but I doubt I'm the first one with
> the idea.
The only thing I've seen is here:
http://www.bitkeeper.com/Products.Comparisons.CVS.html
Besides CVS, they also compare Perforce, Clearcase, and others...no Arch or
SVN though. But it might not be the most "neutral" source, since it is on the
BK website :)
I would also like to see a nice review of various SCM systems. Don't any of
the software dev mags have some articles like this? Google isn't turning up
much...
--
Ben Gollmer
Jatosoft LLC
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: collaborating
Posted by Noel Yap <ya...@yahoo.com>.
--- Paul Lussier <pl...@lanminds.com> wrote:
> If he had done something as simple as used rcs
> within clearcase,
> everything would have been fine. When I saw that BK
> essentially allows
> for exactly that type of behavior I almost cried :)
> Now, I'm not
> saying BK is the best there is, or that it's
> flawless, just that one
> feature is something I've never heard of anywhere
> else, and I see it
> as being a potentially huge benefit to a lot of
> people, and I don't
> see that svn has that on the roadmap either, since
> at this point, svn,
> being simply a better CVS, is inherently a
> centralized system.
> Maybe this is something that can be changed in the
> 2.0 track?
In my current environment, task branches are a no-no
(since they're a pain in CVS). Being able to work off
a local copy of the repo would essentially create a
local task branch thereby allowing me to checkin early
and often while not affecting the rest of the
repository users. Of course, Subversion lends itself
better to supporting task branches, but you can still
count my vote in for this feature being in 2.0 since
the feature would also help offline work.
MTC,
Noel
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: collaborating
Posted by Paul Lussier <pl...@lanminds.com>.
In a message dated: Thu, 10 Oct 2002 23:05:34 +0200
Sebastien Cevey said:
>On Thu, Oct 10, 2002 at 04:42:25PM -0400, Paul Lussier wrote:
>
>OK I am kinda new too, since I read but hardly spoke. :)
>
>> CVS is good, subversion when finished, will be better. However,
>> BitKeeper has some great features that nothing else I know of has,
>> commercial or otherwise! It would be great to have a free
>> BitKeeper.
>
>OK I might have missed the point in the previous mails, and I know
>this is not precisely the topic here, but what exactly does BK have
>that is not planned / impossible in Subversion ? Or, possibly, what
>does svn have that BK doesn't ?
BK has some pretty good graphical tools which let you browse through
the repository and view different changesets, etc.
The one feature I thought was by far the coolest was it's idea of
complete decentralization. IOW, I can clone the "main" repository to
my laptop and check the code in and out from the clone on *my*
system, then later, when I have my network connection back, merge my
local clone back with "main" repository.
Additionally, if I have a cloned repository on my local system,
someone else can come along and check it out from me, inheriting all
my changes.
But I think the aspect I like most about this feature, is the
revision control within concept. IOW, I can clone the master
repository, then check in and out against that as I make changes to
the source. So if I realize at some point that I screwed up
somewhere, I can go back and check out that certain rev.
This feature is something I would have loved to have had in a
ClearCase environment a few years ago. Everyone was developing
against the main line and would keep files checked out for months.
One guy had a bad habit of "accidently" rm'ing his tree. (of course,
the development process these people used was inherently broken, but
I had no power to fix that particular problem). Restoring his data
was virtually impossible because of the way CC stores data within
it's "views", and checking back out from the VOB would only get him
the files he had originally checked out 3 months ago, losing him 3
months worth of work.
If he had done something as simple as used rcs within clearcase,
everything would have been fine. When I saw that BK essentially allows
for exactly that type of behavior I almost cried :) Now, I'm not
saying BK is the best there is, or that it's flawless, just that one
feature is something I've never heard of anywhere else, and I see it
as being a potentially huge benefit to a lot of people, and I don't
see that svn has that on the roadmap either, since at this point, svn,
being simply a better CVS, is inherently a centralized system.
Maybe this is something that can be changed in the 2.0 track?
--
Seeya,
Paul
--
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: collaborating
Posted by Sebastien Cevey <se...@cine7.net>.
On Thu, Oct 10, 2002 at 04:42:25PM -0400, Paul Lussier wrote:
OK I am kinda new too, since I read but hardly spoke. :)
> CVS is good, subversion when finished, will be better. However,
> BitKeeper has some great features that nothing else I know of has,
> commercial or otherwise! It would be great to have a free
> BitKeeper.
OK I might have missed the point in the previous mails, and I know
this is not precisely the topic here, but what exactly does BK have
that is not planned / impossible in Subversion ? Or, possibly, what
does svn have that BK doesn't ?
I'm just an open guy, I will never use BK since I cannot afford it,
and I truly support OSS and thus SVN, but I would love to know what we
are exactly talking about.
If there is any *neutral* paper on the Net comparing CVS, SVN, Arch,
BK and friends (foes?), it'd be really nice. If not, I might even be
interested in writing one actually, but I doubt I'm the first one with
the idea.
The purpose of this is not to point out "what is not in subversion",
but rather to have a global look on SCM. Maybe some projects just
don't suit SVN ?
[ I know, this might be what you are trying to avoid. ]
[ Totally off-topic, sorry : Why not set a Reply-To header in this
mailing list ? ]
--
Sebastien Cevey <se...@cine7.net>
Cine7 - www.cine7.net
Milcis - www.milcis.net
ICQ: 48895760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: collaborating
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Tom Lord <lo...@regexps.com> writes:
> First, saying "drastic" makes a presumption that may very well turn
> out to be false. I don't see how either of us can tell how far this
> would take you off your current path unless we actually think it
> through. If you can not, now and again, stop to rethink -- then there
> is something organizationally broken on your end.
:-)
Why the smiley? Because anyone who's watched Subversion from the
beginning has seen us stop and rethink many things.
Successful projects strike a balance between marching blindly ahead
according to The Plan, and redesigning so often that the project never
matures. We've all seen more free software projects fail than
survive, and though I have no hard evidence for it, my own experience
is that they die as often from overeager redesign and scope expansion
as from failure to be flexible.
Subversion strikes a pretty good balance between these two, and that's
why it's useable software with a flourishing development community
today.
Naturally, every time Subversion gets somewhere, even more delicious
destinations will become visible on the distant horizon. But that
doesn't mean we should immediately head for them, without bothering to
secure the ground we've already arrived at.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: collaborating
Posted by Ben Collins-Sussman <su...@collab.net>.
Tom Lord <lo...@regexps.com> writes:
> > But Subversion can't afford a drastic redesign.
>
> First, saying "drastic" makes a presumption that may very well turn
> out to be false. I don't see how either of us can tell how far this
> would take you off your current path unless we actually think it
> through.
Let me address this --
We've been working on svn for over two years now, and we *have* taken
notice of other scm systems along the way. We've not been driving
with blinders on. We've read about the philosophy behind Bitkeeper,
Perforce, Clearcase, and other systems. We have a general grasp of
their designs, and a *very* good idea of how radically different they
are from the CVS Design that we're seeking to perfect.
So when you ask us to "stop and re-evaluate, and try to imagine what
the perfect scm system would be", it's pretty obvious to us (or to me,
at least) that such a system would be *nothing* at all like CVS or
Subversion. Based on my experience, I don't believe that the CVS
model is even close.
That's why it's so easy for me to state this opinion: switching our
goal to "design a perfect system" is essentially equivalent to tossing
all of Subversion out the window.
So I don't think it's going to be easy to persuade people here to just
"stop coding and discuss scope". But I *do* admire your goal. I hope
you're able to form a consortium/discussion group/whatever, and that
this team designs a new generation of tools, as well as a patch
format. But it needs to happen in parallel with svn, not in serial.
If the consortium comes up with a new set of 'standard' scm semantics,
or a new 'standard' patch format, then svn can grow to incorporate
that standard. And hopefully many svn developers will participate in
such a forum... but please don't expect the forum to halt svn in its
tracks. That's just not realistic.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: collaborating
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Brian Behlendorf <br...@collab.net> writes:
> I will. CN has been working on SVN for two years, which is short compared
> to how long it takes something like Apache 2.0 or Mozilla to reach
> maturity, but an eternity when it comes to a startup funding pure R&D.
> We've got a schedule and a feature set for 1.0 that we all like; I heard
> similar sentiments from others in this thread. I think it's great to
> explore this idea, put some code to words, etc; but those of us focused on
> 1.0 need to stay focused on that. We can't afford to take another year on
> this; we know that what 1.0 has will help us get real paying customers
> that'll help keep the CN SVN developers' salaries paid.
Amen.
And I will add, Tom, that I wasn't actually speaking for CollabNet
when I posted. I just meant that, purely from the point of view of a
free software project that needs to keep its development community, we
shouldn't stop-and-review the whole thing now. People tend to drift
off when a project spends too much time in design phases. We need our
warm bodies to stay right here and keep supplying the heat...
I like my CollabNet salary too, don't get me wrong :-). But there are
also very good reasons to stay focused on 1.0 that have nothing to do
with CollabNet.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: collaborating
Posted by Brian Behlendorf <br...@collab.net>.
On Thu, 10 Oct 2002, Tom Lord wrote:
> Third, on the question of what is "affordable" -- is that your call?
> or are you speaking for collabnet?
I will. CN has been working on SVN for two years, which is short compared
to how long it takes something like Apache 2.0 or Mozilla to reach
maturity, but an eternity when it comes to a startup funding pure R&D.
We've got a schedule and a feature set for 1.0 that we all like; I heard
similar sentiments from others in this thread. I think it's great to
explore this idea, put some code to words, etc; but those of us focused on
1.0 need to stay focused on that. We can't afford to take another year on
this; we know that what 1.0 has will help us get real paying customers
that'll help keep the CN SVN developers' salaries paid.
That said, by all means, start spec'ing out 2.0. Don't hold up 1.0
development, though.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: collaborating
Posted by Tom Lord <lo...@regexps.com>.
> But Subversion can't afford a drastic redesign.
First, saying "drastic" makes a presumption that may very well turn
out to be false. I don't see how either of us can tell how far this
would take you off your current path unless we actually think it
through. If you can not, now and again, stop to rethink -- then there
is something organizationally broken on your end.
Second, "afford" is an economic question. I believe that this effort
can be framed so as to be self-funding, with customers. I believe it
is important to do it that way.
Third, on the question of what is "affordable" -- is that your call?
or are you speaking for collabnet?
Fourth, if this were a game show, I'd wager that I could kill
(obliterate, cream, reduce to a smear on the sidewalk of history)
BitKeeper for $1.5-3M, 1-2 years, with several nice side-effect,
spin-off projects to boot. What's your burn rate over there?
> A complete rescoping at this point would be insanity, from a
> project management point of view.
In general, Don't Panic. Planning is cheap and pays off. You have
lots of code and other resources. Even in the most wildly divergent
scenarios, it seems plausible to me that considerable chunks of those
resources are usefully reusable.
Insanity is marching into the Russian countryside in the middle of
winter because That's The Plan and I'm Sticking to It.
> If you still think you can help, given the above, then great!
> But we'll understand if you feel it's impossible.
Right back atchya.
> But if *you* think Subversion could be redesigned to replace
> BitKeeper and still brought to a releaseable state before the
> heat death of the universe,
I'm trying to avoid presumptions about the outcome of a
stop-and-review effort. Generally, good review efforts save money,
align efforts, and get to market quicker.
The scope I've outlined seems to fit collabnet's charter, even if not
its current design orientation.
> The recent BitKeeper license changes doesn't affect any of
> this, btw.
No, it only effects your prospective customers, that's all.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: collaborating
Posted by Paul Lussier <pl...@lanminds.com>.
In a message dated: 10 Oct 2002 15:03:23 CDT
Karl Fogel said:
>Ahhh. Okay, I see what you're driving at.
>
>I agree with your observations about the scope of the general revision
>control problem. But Subversion can't afford a drastic redesign. We
>decided early on about the problem we were solving -- replacing CVS --
>and the software is targeted squarely at that problem.
I know I'm new here, and am not a contributor in any sense, so I
don't really have any say either, but isn't there a way that both
could be accomplished?
Remember Fred Brook's addage, "Be prepared to throw one away".
Does CVS really need replacing? It's hobbled along for so long that
everyone using it is pretty comfortable with the way it works.
Couldn't they survive until not only something better came along, but
until the *best* something else came along?
What if the goals were re-aligned now and rather than having the goal
of "doing everything CVS does but better", change the goal to be
"the best possible Free source code management system available".
CVS is good, subversion when finished, will be better.
However, BitKeeper has some great features that nothing else I know
of has, commercial or otherwise! It would be great to have a free
BitKeeper.
Just my $.0000000000001.
Thanks,
--
Seeya,
Paul
--
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org