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

Re: [PATCH] issue #97: items are not always checked when dialog reopens

From: Tobias Schäfer <tobiasschaefer_at_gmx.de>
Date: 2006-11-26 09:51:06 CET

On Sunday 26 November 2006 09:19, Stefan Küng wrote:
> Tobias Schäfer wrote:

> > Call commit on a directory which contains a modified file which is out
> > of date. All other files in the directory should be unmodified, so that
> > you do not need to uncheck any items. This will make TortoiseSVN do a
> > recursive commit on the directory.
> > After confirming the commit dialog you see that the file is out of date
> > and the commit dialog re-opens. So far so good, but you will notice
> > that the previously checked state of the file is not restored. The
> > attached patch fixes this.
>
> Fine by me. Go ahead and commit.

Committed in revision 8124 and merged into 1.4.x in revision 8125. It took a
bit longer because I broke my TortoiseSVN installation - details will
follow if I manage to reproduce it.

> > Same scenario as above, but the file is up to date. As soon as the
> > commit dialog opens for the first time modify a further file in the
> > directory. Do *not* refresh the commit dialog so it still only lists
> > one modifed file. Now call commit and you will notice two files being
> > sent to the server. The reason for this: TortoiseSVN does a recursive
> > commit on the directory because no files where unchecked but
> > unfortunately a file was modified later which then gets commited.
> > A solution would be to rescan the directory before actually committing
> > but this would never be perfect because the files might be changed
> > after the rescan has taken place and before the subversion library has
> > taken care of the commit. Should we live with this corner case?
>
> That's an edge case we now live with since the beginning of TSVN. I
> don't think it's that dangerous.
> The problem is that if we don't commit recursively if everything is
> checked, then committing deleted folders won't work.

We could change the logic to only do a recursive commit if at least one
deleted folder is selected and fall back to non-recursive in all other
cases. That would fix the error in my scenario and make it less unlikely to
run into the edge case.

SIFAI (should I file an issue)?

Tobias

-- 
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Nov 26 09:51:45 2006

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

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