On Wed, Aug 5, 2009 at 7:29 AM, Nick Sabalausky <business4_at_semitwist.com>wrote:
> 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.
Specifcally, what 'inconsistencies' are you referring to here?
>
> >>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.
>
That statement is akin to saying that financial reports for a large company
can be done by hand very easily. Accounting systems just make it harder to
mess it up. Have you actually tried to manage a multi-million line software
project 'by hand', including binaries and other 'non-mergable' files?
> >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.
>
No-one is anything of the sort. However, so far you have been the only one
that seems to have the issue with needing to commit the entire WC without
navigating to the WC root first. If this 'problem' was more prevalent among
the user community, then I'm sure the TSVN developers would consider a
solution.
> > 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.
>
Touche.
<snipped />
Daniel B.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2380296
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-08-05 07:56:19 CEST