On Tue, Aug 4, 2009 at 8:30 PM, Nick Sabalausky
<bus_monster2_at_semitwist.com>wrote:
> Daniel Becroft <djcbecroft at gmail dot com> Full name Daniel Becroft
> <djcbecroft at gmail dot com> Date 2009-08-03 16:00:03 PDT
>
> >Should 'unversioned' files be automatically selected for add as well?
> >Missing files be automatically selected for deletion?
>
> No. I'm not sure I see why they would.
>
> >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.
>
Okay, so how do you know what has been modified? Do you use the list
provided in the Commit Dialog, or use Check for Modifications? Manually?
>
> >> 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.
> >
>
> ??? If foo B is gone, then foo B is gone. I'm not sure what you're saying
> here.
>
Foo B is present in the working copy until you either (a) delete it; or (b)
overwrite it - both of which are explicit actions that you would need to
take. If you modify it, then it becomes FooC, but the changes are not lost.
FooC = FooB + Changes
>
> >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.
Okay, so in order to determine that, TSVN basically would have to parse *the
entire tree* under the working copy, not just the first level.
> But I don't see how this scenario is relevant anyway?
>
You have requested a new feature be added to TSVN, and that feature is the
ability, from anywhere within the working copy structure, to commit as
through it was from the WC root. I am just raising questions regarding how
you see this functionality acting. Since you raised the feature request, you
are the best person to describe how you expect the functionality should work
in all situations, and that includes externals.
>
> >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.
No, the very nature of VCS is to preserve the history of files. For example,
SVN will allow you to delete the entire trunk directory from your
repository, without interference. There will be a history of where trunk
used to be, but it won't prevent what is quite obviously a mistake.
Alternatively, it will allow you to commit gigabytes of garbage without
objection (filesystem limits not withstanding).
<snipped />
Cheers,
Daniel B.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2380241
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-08-05 07:16:31 CEST