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

Re: Feature Request: Option to *always* commit all the changes in the *entire* working copy.

From: Nick Sabalausky <business4_at_semitwist.com>
Date: Tue, 4 Aug 2009 17:29:24 -0400

levyam Full name Andy Levy Date 2009-08-04 05:24:45 PDT
>>Just out of curiousity, when the files are selected in the commit dialog,
>>do
>>you double-check each one to ensure the changes are to be committed? Ie
>>there are not debug messages, etc that should be removed?
>
> No. I always remove such things even before deciding to commit.

>And you've never made an error? I'm a little surprised that if you're
>so meticulous about this, you're so sloppy about where you perform
>your commits from, and not reviewing what you're committing.

If you can rephrase that without resorting to tossing insults, I may respond
to it.

>>If someone accidentally checks-out a working copy into the root of C:\
>>(for
>>example), then the root of the WC will be C:\, and every directory under
>>that will probably show up as a unversioned directory. If there's another
>>working copy located at C:\files\work, should 'files' should up in the
>>list
>>(as it contains WC that cannot be added)?
>
> Of course not. But I don't see how this scenario is relevant anyway?

>Because in these scenarios, TSVN would have to walk a lot more of the
>tree than you think.

First of all, that's a highly contrived scenario.

Secondly:

dirToCommit = getWhateverDirTheUserSelectedAsUsual;
if(proposedOptionIsEnabled)
{
   while(dirToCommit.hasParent && dirToCommit.parent.isVersioned)
   {
      dirToCommit = dirToCommit.parent;
   }
}
checkForChangesAsUsual(dirToCommit);
displayCommitDialogAsUsual();

If the user commit at a dir within C:\files\work, it stops at C:\files\work
because C:\files is unversioned, so there's no reason to go any further.

Now if someone accidentally makes another checkout at C:\files, that's still
easy to detect as being a separate wc because of inconsistencies in
structure and checkin location.

>>That wasn't arrogance. By your own admission, it's a 'mistake' that these
>>files are not committed. That's a user mistake, NOT a software mistake.
>
> The very nature of VCSes ultimately boils down to preventing user
> mistakes.

>I think you misunderstand that nature. VCSes are meant to preserve
>your data and change history in the repository.

Which can all be done by hand very easily. VCSes just make it harder to mess
it up.

>If you commit poorly,
>you'll get poor results. The repository doesn't and can't understand
>the context and semantics of what you're putting into it, it can just
>ensure that your bits are tracked properly.

I think you misunderstand the nature of software. Of course software can,
and often should, anticipate user mistakes and provide ways to mitigate
them. Examples:

User errors that software already can, should, and does solve:
- User can type something wrong. Solution: Undo/redo.
- User can delete a file by mistake. Solution: Trash Can/Recycling Bin and
Confirmation dialogs.
- User can misspell something. Solution: Spellcheck with correction.
- User can read across a row in a table and skip to the wring row without
realizing it. Solution: Grid lines and alternating background colors.
- Artist can accidentally drag to a point near, but not on, the exact point
they intended. Solution: "Snap to"
- Coders can make a datatype error. Solution: Type systems, either static or
dynamic.
- Coders can forget to free memory/resources. Solution: Automatic memory
management and RAII.
- Coders can forget to check for an error condition. Solution: Exceptions.

You can argue all you want that software can't infer user intent, but the
examples above quite clearly demonstate that's no excuse for software
develpers to dismiss user errors as the user's own problem, as you are
trying to do.

And if after all that you're still blind to the existence of and usefulness
of detecting/preventing user errors, then there's no point in continuing
this discussion.

> I was saying that such problems
> that can reasonably be prevented by software should be prevented by
> software.

>An option which is presented to the user but poorly understood because
>the user doesn't understand the use case

I understand the use case perfectly well, and I'm asserting that the current
measures are unsatisfactory.

And stop trying insist I don't understand it, because that just leads the
discussion in circles. "Yes I do, No you don't, Yes I do, No You don't".

>(note how many people are not
>speaking up and saying "yes, I work this way too")

The number of people who have responded at all hardly constitutes a
meaningful sample size.

>is just as
>dangerous as not having the option at all. I can envision one of my
>users seeing this, thinking it's convenient, turning it on, and then
>coming to me to get a commit reversed because they committed a whole
>bunch of things they didn't want committed.

Then see the other suggestion about merely offering an optional warning when
there are unselected changes in the wc outside the selected dir, and stop
trying to automatically dismiss everything I say.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2380178

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-08-05 07:15:13 CEST

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