> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> Sent: Monday, April 14, 2003 5:07 PM
> Earlier, I made encouraging noises about getting improved merge
> (a.k.a. changeset) support into Subversion before 1.0. Even though I
> didn't have much time to work on it myself, I thought "What harm? If
> people can get this stuff done, then Subversion will be that much
> better off when it hits 1.0".
>
> I was wrong, though. Sure, the changeset discussion has been
> productive, in the sense that many design issues are being worked out
> (without even any major flamewars, which is nice!).
Exactly. This is the reason I want this discussion to continue.
On the dev@ list, where it is archived and people can read what is
being thought up. At the same time I can see that this is a
(potential) massive resource hog. Therefor I suggest that the people
who don't have the time for this don't read the full threads. Instead
I (or anyone else) will create a document in notes/, which will be
amended throughout the discussion. Each time the doc is in a state
that it could use some review (but no more than twice a month), the
dev list will be notified and the people low on time can then use their
precious time efficiently, not having to plough through long threads.
This will also hopefully have the effect that we don't have to start this
discussion all over again post 1.0.
> But it's also sucked a lot of Generic Fungible Dev List Energy away from other
> concerns that are, IMHO, much more pressing. I was foolish to think
> that the effort could come at no cost. A feature like this simply
> can't be tacked on by a small group of volunteers, it really needs
> widespread participation.
Which can be asynchronous, as long as there is some checkpointing.
The above compromise should do nicely.
> As Tom has pointed out, version control is hard.
AFAI have seen, we've been quite well with the merge design. I still
haven't seen big holes shot in it.
> This is certainly not a veto on changeset-related work. However, I
> personally am dropping out of it now, and don't plan to work on it
> before 1.0. To the extent that I can influence others, I would like
> to encourage -- beg, plead, beseech -- that they do the same. Way,
> way too many basic bugs are coming in. If we had a listwide consensus
> to defer this particular set of complex features to Post-1.0, that
> would be a great thing.
See you at the next checkpoint ;).
> [I could end here, but noooo...]
>
> Right now, I see all these exciting posts about adding merge support
> that goes far beyond what CVS does -- and then I go look at the bug
> database and reality hits me hard. What the heck were we *thinking*,
> folks? Just look over that bug summary list. Why are we talking
> about adding changesets, when we don't even have freakin' restartable
> checkouts? When we have known performance and scalability problems on
> real-world data sets? When we have so many known correctness issues
> in our core code?
We can't let that stop us. Are you saying noone should work on any
new features, design or implementation, while there are known bugs?
Remember, there are a lot of different people here, all with different
skills. If all we can do is fix bugs a lot of resources will go to
waste.
> I'm not mad at anyone here -- I was seduced too.
*grin* It's a wonderful problem to solve ;).
> But truly, it's unrealistic to expect to ever release 1.0 if we don't
> stop with the new features and start dealing with the issues we already have.
Nah, as long as not all of us are going to head off and discuss merging
full time there is nothing to worry about.
> Let's behave like a successful project, and maybe we'll be one :-).
I bet you can name lots of projects that have been succesfull and not
because they don't have any known bugs, but because of their features :).
> Enough said. See you in the bug database, I hope,
LOL! I certainly hope that our dedicated crowd keeps visiting the bugs
database and keeps closing bugs ;).
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 14 21:27:43 2003