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

odd cases

From: Jim Blandy <jimb_at_savonarola.red-bean.com>
Date: 2000-09-05 21:38:57 CEST

Suppose a user has a working directory containing a file, A, based on
version 10 (which I'll write `A:10').

Assume that commits happen only when I explicitly say so; otherwise,
changes are just local to the working copy. Assume that all copies,
renames, etc. are done via the appropriate Subversion commands.

The user copies A to B, yielding a new file B, based on A:10.

The user updates the entire directory, and A is now based on version
11; B is noted as an added, but not yet committed, file.

The user deletes A.

The user renames B to A. Now the working copy's A is based on A:10.

Now, suppose the user does an update. No further changes have been
committed by anyone to the repository. Should A be brought up to
version 11? I think it shouldn't --- A's current text is something
the user explicitly chose. Their working copy is completely
up-to-date. I think Subversion should simply note that A is "locally
modified", and leave its contents alone. Do you agree?

Now, suppose the user does a commit. Should Subversion complain that
A is not up to date? Or should it simply check in the current
contents of the file --- effectively reverting the change made to A in
version 11? I think it should do the latter. This is the same
question as above, I think: "Is this file up-to-date?"

Now, when the user does a commit, what callbacks to the
svn_delta_walk_t structure need to happen? A single call to
replace_file doesn't work; the filesystem can't tell the difference
between that and attempting to commit an out-of-date version of A. I
think it needs to do a `delete', and then an `add_file'. I'm not so
sure about that. What do you think?
Received on Sat Oct 21 14:36:07 2006

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