On Tuesday 06 August 2002 18:31, Karl Fogel wrote:
> Aiyyaaaaaaaaaa :-).
Interesting... :-)
> You probably don't know it, but about once a month, someone (usually
> new to the project) brings this up, and we always say the same thing:
>
> We're not going to do this before 1.0. We don't know if we're going
> to do it after 1.0. Personally, I think if people want to update,
> they should run "svn update". It's not that hard :-). But raise the
> topic up again after 1.0 if you want.
Things are easy in an ideal world...
> The fact that such support is "usually implemented in those large,
> extremely expensive, commercial tools" is not an argument. What would
> be persuasive would be a tale of how you (or someone you know) got
> bitten by not having the long transaction model.
Yes, the argument sucks, I really regret writing it! What I perhaps meant was
that the commercial (Thanks, for correcting my spelling, BTW) tools that I
know of (except that abominable MS contrib), actually leaves decisions about
the commit policy to the user (the manager of the repository), which I
believe is quite good. (Rational ClearCase is one example, although the
general complexity of that system --- and certainly its price --- makes it
unusable for small projects. Still, believe it or not, many large companies
at least own it, and are desperately trying to understand how to use it.)
Policies differ as I said, although perhaps not that much in the so called
"open-source community", since until now, CVS has dictated the rules in most
of the cases.
The most persuasive argument I can come up with right now is, again, that I
think that the users' freedom of choice, regarding things such as commit
policies in their projects, would be well worth trying to satisfy. Just as
the way Subversion supports, for example, 3-way diffing/merging for those
users that want to use it. The fact that this topic is brought up once a
month does also imply that there are people other than me who want this
feature.
What I'm personally into right now, is finding a replacement for CVS in
student software engineering projects, which takes place every year at the
Lund Institute of Technology.
At our Department of Computer Science, where I work, we're interested in
research on agile process models in general, specifically with some focus on
software configuration management. We have a group of researchers and a
professor with long experience in this area.
We have used different tools, free and commercial, for versioning during the
years of the project course that I mentioned. All of them, of course, have
their respective advantages and drawbacks. Things we have specifically been
lacking in CVS are the strict long transactions (for the reasons I tried to
describe in my last contrib to the list) _and_ features among all of which
Subversion certainly comes up with the right solutions, as far as we believe.
I'm sorry if I'm tedious in my formulations.
> By the way, I just tested your claim about CVS in local mode...
> ... and it is not true with CVS 1.11p1 with local repository. Bob was
> able to commit without updating.
Yes, he is if he explicitly commits just "his" file using 'cvs ci bar.c', an
action that should also be forbidden in the LT model, as far as I see it. But
'cvs ci' inside dir/ is rejected in CVS 1.11.1p1, which is the version I
assume you meant.
--
Ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 6 21:00:44 2002