[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: Daniel Becroft <djcbecroft_at_gmail.com>
Date: Tue, 4 Aug 2009 08:59:59 +1000

On Mon, Aug 3, 2009 at 7:19 AM, Nick Sabalausky <business4_at_semitwist.com>wrote:

> levyam Full name Andy Levy Date 2009-08-02 03:33:55 PDT Message On Sat, Aug
> 1, 2009 at 21:49, Nick Sabalausky<busine?ss4_at_semitwist.com?> wrote:
> >> Currently, if you do a commit from a subdirectory within the working
> >> copy,
> >> only the changes within that subdirectory are selected for the commit.
> >
> >Which is the behavior pretty much everyone expects. If you select a
> >directory, it's assumed that you intended to operate on that
> >particular directory.
> Which is why I'm asking for it to be an ***OPTION***.

Should 'unversioned' files be automatically selected for add as well?
Missing files be automatically selected for deletion?

> >> I *never* want to do that, but it constantly happens to me by mistake,
> >> and
> >> since there's no notice that that happened,
> >
> >Sure there is. It's pretty clear which directory you're working on.
> Normally yes, but when I'm juggling a million different concerns (as is
> normally the case in any non-trivial software development), it is easy to
> ***OVERLOOK***.
> >> I don't always realize until
> >> it's too late (ie the changes have already been replaced by newer
> >> changes,
> >> and that particular snapshot that I *thought* I committed is lost
> >> forever,
> >> and that particular revision is effectively corrupted.)
> >
> >This makes no sense to me. What's "corrupted" and how? It's only your
> >working copy and nothing will be replaced that you don't ask for.
> The newly committed revision is corrupted. Ie, If I make a modification
> that
> involves changes to four files, I commit only two of those changed files,
> and someone checks out the revision I just made, then clearly it's unlikely
> to work.

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?

> >> I consider this a very serious data loss problem. I need an option to
> >> disable that behavior and force all commits to auto-select all the
> >> changes
> >> in the working copy to be commited, and never just a subset of the
> >> changes.
> >
> >How is your data lost?
> How isn't it? I'll explain again: I have file 'foo'. At this point we'll
> call it version A. I then make a change and now have B. I do a commit, and
> some other stuff gets committes, but 'foo' doesn't and since I expect
> commits to just work, I don't notice. So I continue and make another change
> and now have C. I then commit 'foo' C (successfully this time), and shut
> down for the day. At this point, 'foo' B is clearly gone.

The intermediate version, 'foo' B is gone, yes. However, the changes (unless
you removed them) will still be in 'foo' B.

> >So you want TSVN to recursively walk UP the directory tree? This is
> >potentially a very expensive operation,
> Expensive to walk up a directory tree? Not at all. Certainly not compared
> to
> all the other work involved in a typical commit (such as diffing files and
> transferring data across a network).

Expensive to walk up, no. Expensive to then traverse back down and obtain
all the changes from all the portential child directories? Most definitely.
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)?

> >and can cause some odd
> >behavior if you've got externals mixed in there as well.
> How so? But regardless, I haven't been using externals, so I could live
> with
> that.
> >What you're describing here is asking TSVN to make a very large change
> >in its behavior
> I'm only asking for it as an *option*.

> > due to your own carelessness. Slow down and be more
> >careful about what you're doing. You're given plenty of opportunities
> >to review what's being committed before it happens.
> That is completely uncalled for. Don't be so damn arrogant.

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.

> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe_at_tortoisesvn.tigris.org].


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-08-04 07:14:10 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.