On Tuesday 06 August 2002 17:01, Karl Fogel wrote:
> If CVS local really behaves the way you describe, it's a bug. But I
> find it hard to believe that no one would have noticed this by now.
The reason that few people may have noticed this in CVS, could be that CVS is
usually used with a remote repository, where the behavior is different from
the local repository situation. Maybe it's a bug that the long transaction
model shows up by default in the latter case, but using the commitinfo
concept of CVS, this behavior can be configured, although it is quite
difficult.
> Both to be compatible with CVS, and because we think it's useful to
> not enforce strict updating, so people can retain fine control over
> the state of their working copy while still being able to commit. In
> practice, few problems seem to arise from this model (since it's the
> CVS model too, there's a *lot* of practice to draw on).
I don't think it's useful to enforce _anything_ regarding the integration
management. Different sites use different policies. Let's say, for example,
that a team likes to work under the invariant of a compilable/testable
repository at any time. (I beleive this is a common situation.) Since the
files of a software module are not usually completely independent (for
compilability/testability), only the long transaction model fully supports
the policy of making all integration in the working copy, where compilability
and testability can be verified. In CVS / Subversion, repository correctness
under the above invariant can not be guaranteed. Two persons can obviously
make changes to different files, still be able both to compile and test in
their respective sandboxes, but this may not be the case after the second
commit, if their changes happen to be "conflicting". But the second commit is
still legal from the Version Control System point of view.
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.
--
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 18:37:44 2002