Josef Wolf <jw@raven.inka.de> writes:
> Hello!
>
> I'm very sorry for posting to the wrong list! I hope I get it right
> this time.
No worries!
> From: Ben Collins-Sussman <sussman@collab.net>
> > If I run 'svn ci', and 3 files are sent to the server, and I create
> > revision 10, how on earth would I know that it's okay to label *all*
> > of the files in my working copy as being at revision 10? Certainly,
> > some of the files I *didn't* commit might have been changed by other
> > people between revisions 5 and 10.
>
> As I mentioned in my original mail you would be right if the command
> were "svn ci write/search.c". But "svn ci" has the semantics of
> "commit everything". In this case the server should refuse the commit,
> because the up-to-date-test failed. Please note that my Proposal
> explicitly excluded the case where you commit only a subset of files.
"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.
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.
It's actually impossible to commit an unchanged file. If foo.c were
unchanged, and you said " svn ci foo.c", nothing would happen.
There's no change to commit. :-)
> >> I understand that
> >> committing should be a one-way-operation and should not touch your
> >> working files.
>
> > Well, there you go. Commit is a client->server write operation. I
> > don't think most people want a commit to be two-way write operation.
> > I certainly don't;
>
> 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. Commits write to the server, updates write to the
working copy. Where is the "error proneness"? 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.
> > Mixed-revision working copies are a normal thing. They're a normal
> > part of life in CVS, so we've kept the same flexibility in SVN.
>
> This is a normal thing in _CVS_. But SVN came up to eliminate some
> cvs-issues. So why not eliminate _this_ issue, too? There could be a
> configuration option so people could choose which behavior they like.
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!
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!
I can't even imagine it as a configuration option: why would people
want to eliminate their ability to have mixed-revision working copies?
> > The tag? Not sure what you want. Perhaps the HeadURL keyword?
> > Remember that branches and tags are just ordinary directories
> > (locations). $HeadURL$ is the "location" of the file.
>
> This seems to be exactly what I was looking for!
Great!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 25 23:38:42 2002