Roel Harbers wrote:
> From: Roel Harbers <roel <at> roelharbers.com>
> Subject: Re: Bug or Feature? Commit Selection ignored
> Newsgroups: gmane.comp.version-control.subversion.tortoisesvn.devel
> Date: 2007-05-14 08:29:09 GMT (12 minutes ago)
>
>
> Slim and Steve wrote:
> > I guess it is considered as a feature that just escapes me,
>
> Sounds like a bug to me
>
> > 1) start commit dialog through right click menue in file manager;
> >
> > 2) select some of the files and enter the commit message;
> >
> > 3) leave it as it is (repository not available on the LAN, a
> > customer calls in, anything that keeps you from fnishing by hitting
> > the commit button);
> >
> > 4) computer goes into standby or hibernation (these are laptops
> > though used stationary most of the time);
> >
> > 5) after reactivation the commit dialog is as it was before;
> >
> > 6) click on commit and ...
> >
> > 7) *all* modified/added/deleted files will be committed, no matter
> > if they were selected or not. Equally files modified/added/deleted
> > since originally calling the commit dialog.
>
> I cannot reproduce this with either hibernation or standby in the
> nightly build (TortoiseSVN 1.4.3, Build 9406 - 32 Bit -dev, 2007/05/13
> 22:41:27)
>
> Does it happen everytime your system goes to sleep? Can you verify if
> it happens after either standby or hibernation, or just one of them?
>
> Does it happen with any kind of change, eg. two files modified in the
> root folder, and selecting only one, or only with more complex changes
> with deletes and adds in subfolders, etc?
Testing with a test repository/working copy gave some clues:
1) checkout WC with three files: foo.txt, bar.txt, newfoo.txt
2) modify foo.txt && bar.txt
3) call commit dialog and select foo.txt
4) standby/hibernate - wakeup cycle
5) commit: only foo.txt is committed in both cases
That's okay. Now another attempt:
1) modify foo.txt && bar.txt
2) call commit dialog and select foo.txt && bar.txt (or just leave
them selected)
3) standby/hibernate - wakeup cycle
4) modify newfoo.txt
5) now foo.txt, bar.txt, newfoo.txt are committed (newfoo.txt should
have not)
That's not okay, but what happened to me several times this last
year or so. It is, however, exactly what Stefan Fuhrmann described
in his other reply, only that I should have done this test before
posting - with three files things are a little easier to figure than with
a whole bunch, furthermore interspersed with files not yet/never to
be added. When it happened I never paid attention to the thought if
I had specifically selected some files or if it happened to be all
modified files under version control.
Looks like a workaround necessitating another workaround in some
cases. ;)
> > It really is not funny, breaking the idea of meaningful revisions.
> > Like just committing everything before lunch and before going home,
> > no matter if things belong together or are ready for commission into
> > trunk. I'd rather go back and edit commit lists for the command
> > line ...
>
> That's entirely your call, but personally, I'd say that's a bit
> drastic.
Nah, it's not too bad - did it long enough intentionally before setting
up TSVN at all. Just a little nastier, that's all. And on the XP
machine even not that much given the stupid irritating full path
popup on cursor (mouse completely out of the window) movement
in the file list I never could turn off as in W2K.
Thanks both of you!
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue May 15 13:16:26 2007