Olaf van der Spek <olafvdspek_at_gmail.com> wrote:
> > Commits don't fail often for me even under the adverse
> > conditions I described. Less than 10% maybe.
> > However, there is a situation when TSVN could be more
> > supportive: Whenever the items I try to commit were
> > outdated. While this is a rare case for me, it will
> > hurt people that frequently restructure folders, do
> > merges or modify properties on folders and don't run
> > update before commit.
> > This is what TSVN could ideally do in that situation:
> Hmm, can't it check for modifications / out of date files before you
The "check for modification" dialog can do that. If you
commit from there, most times you will discover outdated
paths if there are any.
But there are two problems with checking beforehand.
First, it can take quite some time to get the every
path to commit and second, the is still a small chance
some other user committed between your check and your
In fact, the first phase of a commit transaction (before
the "Sending" lines) already performs that out-of-dateness
check but also prevents other committers to modify the
same paths while you are committing.
> > * detect that commit failed with "outdated" error code
> > * show "shall I run update now (Y/N)?" message box
> > * re-open commit dialog, iff update went smoothly.
> > IMHO, we could make *that* a non-optional behavior.
> > Would this address your issues or do you have an
> > entirely different use-case?
> Yes, I think it fails most often due to out of date files.
Implemented in r17466.
It still feels like a lot of clicking is required to
acknowledge every step of the workflow. "auto-close if
no errors" only saves one click here.
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-10-19 13:50:29 CEST