On Tue, Aug 4, 2009 at 06:30, Nick Sabalausky<bus_monster2_at_semitwist.com> wrote:
>>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.
>>Expensive to walk up, no. Expensive to then traverse back down and obtain
>>all the changes from all the portential child directories? Most definitely.
>
> But that is still no more expensive than if I had done the commit from the
> wc root, which is essentially what I always intend to do anyway.
>
>>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.
>>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. 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 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 (note how many people are not
speaking up and saying "yes, I work this way too") 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.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2379976
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-08-04 14:24:56 CEST