Christian Andersson <chrisand@cs.lth.se> writes:
> With the above motivation, I think it would be a mistake not at least to
> _support_ such a commit strategy or policy in the Subversion tool, in the
> other way or another. Such support is usually implemented in those large,
> extremely expensive, commersial tools on the market. A agree that a good CVS
> compatibility way of doing it, is disabling it by default. It's good if
> people can retain fine control over the states of their working copies, but
> it's also nice with fine control over the state of the repository.
Aiyyaaaaaaaaaa :-).
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.
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.
By the way, I just tested your claim about CVS in local mode:
> Consider a repository head revision
>
> dir/foo.c
> dir/bar.c
>
> and two users Alice and Bob. Alice changes foo.c and commits, creating a new
> version of the repository. At the same time Bob changes bar.c and tries to
> commit just after Alice.
>
> In CVS using local filesystem repository, Bob's commit is rejected,
> thanks to the strict long transaction model. However, when using the
> network implementation of CVS, Bob's commit is accepted, without an
> update. The CVS developers seem to have chosen this solution by
> design --- a choice that I think is wrong.
... and it is not true with CVS 1.11p1 with local repository. Bob was
able to commit without updating.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 6 18:47:13 2002