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].
>
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2379770
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-08-04 07:14:10 CEST