[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Confusing update + commit semantics

From: Gerco Ballintijn <Gerco.Ballintijn_at_cwi.nl>
Date: 2005-09-22 13:08:43 CEST

Erik Huelsmann wrote:

>>I came across the following confusing subversion behavior. When an svn
>>user uses the "svn update" command to return a particular file in a
>>directory, with other modified files, to an older revision (i.e., "down-date"
>>it) and then uses the "svn commit" command to commit the whole directory, the
>>commit command silently ignores the file with the older revision, but commits
>>the other modified files in the directory, leaving the user with the
>>impression that this older revision is also committed (unless explicitly
>>checking the "sending" entries). Is this the intended behavior?
>>
>
>Yes. No changes were made to the older file, so there was nothing to commit.
>What you're looking for is:
>http://svnbook.red-bean.com/en/1.1/ch04s04.html#svn-ch-4-sect-4.2
>

Thanx for your answer.

It is rather unfortunate that subversion considers, in the update case, that
there is nothing to commit. When typing "svn commit" in a directory, one
expects
the current contents of that directory to be committed, irrespective of
whether
the contents was created using "svn merge", "svn update", or by simple
editting.
Well, that's at least what my CVS experienced collegues expect.

The fact that the end result of an "svn merge" is committed, but the end
result
of "svn update" is not, might be technically sound (i.e., is consistent with
the rest of the implementation), it is however confusing for (new) users. It
forces users to know before doing the "down-date" whether the changes should
be committed, if so use a "svn merge", or if not, use a "svn update".
Actually,
related to this, the fact that the "svn update" back-date operation doesn't
"modify" the file (i.e., no M in "svn status") is equally counter
intuitive to
new users.

Wouldn't it be possible to add the notion of a sticky tag to the files
in the
working copy? This would allow users to mark these back-dated files, and
force
the commit to fail visibly (indicating the commit would not result in the
expected repository contents), instead of silently ignoring the unmodified
back-dated file.

Gerco.

Dr. G.C. Ballintijn
Interactive Software Development and Renovation
Center for Mathematics and Computer Science (CWI)
Tel. 020-592 4266
mailto:gerco@cwi.nl
http://homepages.cwi.nl/~gerco/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Sep 22 13:10:46 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.