On Thu, Apr 25, 2002 at 04:35:21PM -0500, Ben Collins-Sussman wrote:
> "svn ci" doesn't mean "commit everything in the working copy". It
> means "commit all files that have been changed". There's a huge
> difference. And this is what it means in CVS as well, which is why we
> kept the semantic.
I wrote "commit everything" and had in my mind "commit all changes". I
see I have to be more accurate in the future :)
> When you run "svn ci" (or "cvs ci"), a process actually crawls your
> working copy and looks for files that have been modified, and only
> commits those files.
Yes, that is what it does by now. And this is exactly what bothers
me.
> > This is your point of view, which I can understand. On the other side,
> > such inconsistencies are very error-prone and I don't think most
> > people want error-prone behavior by default.
>
> This isn't just my point of view: it's a whole paradigm brought to us
> by 10 years of CVS.
OK, but if you want an exact copy of CVS then you have to expalin why
the subversion project exists. AFAIK subversion tries to make some
things better than cvs. AFAICS it actually does _much_ better. CVS
could not do better, because it relies on the file-based RCS. But SVN
_could_ do better because svn is no more file-based but module-based.
But for some reason you don't _want_ it to do better. Ummm...
> Commits write to the server, updates write to the
> working copy. Where is the "error proneness"?
OK, so let me give you an example how this could fail:
1 user1$ svn co # get revision 5
2 user2$ svn co # get revision 5, too
3 user1$ emacs foo.c
4 user2$ emacs bar.c # let's assume the changes made are inconsistent
5 user1$ svn ci # create revision 6
6 user2$ svn ci # create revision 7
Revision 7 will be broken because the changes are inconsistent. IMHO
there should be at least a warning when rev7 is committed. There
will be even more trouble if user2 creates a branch and forgets
the "svn update" before creating the branch. Bar.c will be branched
from revision 7 and all other files (including foo.c) from revision 5.
For sure, you can avoid these errors if you are perfect and all your
co-workers are perfect. But people make errors. They simply _forget_
to "svn update". They simply forget to warn/inform other people about
commits. They simply forget to check whether they were other
commits. When you are in a hurry, you just dont _want_ an error-prone
behavior by default.
> When a user updates,
> they know that they'll only be receiving changes. When a user
> commits, they know that they'll only be sending changes. Blurring the
> behaviors leads to much more unpredictability, I think.
You misunderstood me (is my english really _that_ bad? ;-). I never
mentioned that your working files should be changed on a commit. Only
the administrative files would be changed.
The changes I am proposing are:
1.) (dependant on a config-option) refuse commits if _any_ file fail the
up-to-date-test. This is to make sure your working files will not be
changed in step 2. (OK, I did not include this in my original post)
2.) (dependant on a config-option) give an automatic atomic update
after a commit. Because of step 1.) this won't do any changes to
your working files.
> Sorry, I don't see the "issue" here. I don't believe that
> mixed-revision working copies are a design flaw in CVS. It's actually
> a useful feature that people depend on!
Ummm... I'm using cvs for 10 years now, and I still have no idea what
this "feature" could be good for. Could you give me an example? The
only times I used this "feature" were when I had to to correct the
errors which were caused by this "feature".
> Quite often, people want to backdate files in their source code tree,
> or move whole subdirectories to different branches or revisions. If
> you forced users to *always* have a working copy that resembled some
> pristine tree on the server, I daresay the users would revolt!
If this were a conf-option there would be no reason to revolt. Just
configure it the way you like it.
> I can't even imagine it as a configuration option: why would people
> want to eliminate their ability to have mixed-revision working copies?
I don't want to eliminate mix-rev's. I just don't want them to come up
where I would not expect it. While I still can't understand why you
would want mix-rev's, I have no problem with them if you _explicitly_
call for them. But they should not come up on _every_ commit.
PS: Why do you _want_ mixed revisions? What are they good for? Why is
it good that _every_ commit creates mix-rev's? It seems that I
have missed some very basic thing.
--
-- Josef Wolf -- jw@raven.inka.de --
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 1 04:36:47 2002