Hello!
I'm very sorry for posting to the wrong list! I hope I get it right
this time.
I wrote:
>> The example in Section 2.2 of the "subversion design" paper and in
>> section 1.2 of the "User Manual" seems to be somewhat wired to me. Why
>> dont all the files get updated to revision 5 after the commit? IMHO
>> such inconsistencies should be created only if one explicitly calls
>> for them (for example by commiting only specified files as in
>> "svn ci write/search.c"). But when "svn ci" (which has the semantics
>> of "commit all changes") is used, the versions of all the files should
>> stay consistent if they were consistent before. IMHO should the effect
>> of "svn ci" be the same as "svn ci; svn update".
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.
>> 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.
> just because I send things to the server, doesn't
> mean I'm ready to start accepting changes.
There are no changes done to your working copy. Only your
administrative files in the SVN-directory are changed. Those files are
changed in either case (at least for write/search.c")!
Having different revisions of the files lying around is a very
error-prone thing and (IMHO) should not be the default-behavior.
> 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.
>> It would be nice to have something like 'char *the_version="$Name$";'
>> and get the tag (_not_ the internal version number but something like
>> "subversion-r909"). The only thing I could find in the docs which
>> addresses this was LastChangedRev, but this seems to be substituted
>> with the internal revision number.
> 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!
--
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 Thu Apr 25 23:21:12 2002