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

Re: Misinforming the user on rename with local changes

From: Simon Large <slarge_at_blazepoint.co.uk>
Date: 2004-11-11 16:16:02 CET

François Beausoleil wrote:
Quoting Thomas Hallgren:
> Bob checks out a project.
> Bob edits the file foo.txt.
>
> Bill checks out the same project (and version) as Bob.
> Bill moves the foo.txt to directory bar.
> Bill makes some changes to bar/foo.txt.
> Bill commits his changes.
>
> Bob commits his changes.

> Am I too alarmist, or is that a real concern ? I understand most
> command line users wouldn't have that problem, because they'll be
> doing status real often, but GUI clients might not be doing that
> status so often. I'm thinking of TSVN with deep tree status turned
> off, for example. Part of the tree is hidden from view, so the user
> won't know that his file has been unversionned.

I just tried something like this in TSVN. When Bob tries to commit he
gets the error message as you describe, and updates. Assume for the
moment that he didn't watch the messages, or that they scrolled past too
quick to read. Now he tries to
commit again, and foo.txt is listed as an unversioned file in his commit
dialog. Provided that he has used svn:ignore properly and isn't swamped
with unversioned files, he will (or should) see that.

At worst, he will not see it and his build will be broken, but SVN has
not thrown away any data. He still has his own locally modified foo.txt
_and_ Bill's version in bar/foo.txt.

It's not ideal, and maybe there should be a warning in the update which
would make it more obvious, but I don't see this as a major problem.

Simon

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 11 16:22:00 2004

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