[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: Greywolf <greywolf_at_starwolf.com>
Date: Tue, 4 Aug 2009 13:59:40 -0700 (PDT)

Nick sez:

NS: I have never had a working copy that included both changed files I
NS: was ready to commit and changed files I wasn't ready to commit. In
NS: fact, I don't work in such a way that that would ever happen.

Andy sez:

AL: And I do all the time, because my change management process & timing
AL: requirements more or less require that I do so (otherwise I'd need to
AL: maintain a half-dozen WCs of a single project on my workstation). And
AL: I've never had any problems with Subversion or TSVN resulting from it.
AL: Every one of my commits has had exactly what I wanted and expected
AL: included in it, because I review what's being committed before I click

For what it's worth, I work both ways: Sometimes I make partial commits,
usually right before my project either enters test just before release,
or right before I fork the release "tag". If neither of those is
happening, I make full commits.

[what I'm doing: I have things that depend on a particular version of
a library, which includes components that need to be checked in just
prior to rebuilding the library. The library will be at version
(fileversion + 1), due to the nature of what needs to be done.]

Both of these actions are *intentional*; i.e. I am aware of what I am

I, too, have unintentionally begun a commit before thinking to see where
I was at, from time to time.

This is precisely what the "Cancel" button is for: "Hey, where's all the
other stuff I changed? Oops. Checking in from the wrong spot. Try

So I'm going to weigh in as heavily as a non-externals-using, non-svn-nor-
tsvn-core-dev member can weigh in and say that what is befalling you is
not the responsibility of the app -- it is your responsibility to make
sure you are at the top level before checking stuff in, or to make sure
that if you are doing partial commits, you're conscious of it (as Andy and
I and likely others are). This is going to sound kind of patronising,
and I do apologise in advance, but what needs to change is your conscious
workflow, not the software. When you learn a new operating system, or
are hired on into a new environment, or load up a new app, are the OS,
environment and/or app supposed to adapt to you? Or does it work the
other way around?

Think of it this way: If you're in a very high-level directory and you,
say, type "rm -r ./somedir". It is not going to warn you that you are
potentially removing a lot of stuff and/or a lot of potential state. It
is going to go off and do it and only give an error if it encounters
something it cannot handle (read-only directory, segmentation fault after
removing libc.so, etc.). Whose fault is it that you typed in the wrong
thing at the wrong place?


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-08-04 22:59:51 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.