> From what I understand, TortoiseSVN already helps you with both of
> these tasks. When you commit, it pops up a list of files about to
> be committed, and you can uncheck a checkbox before each filename
> to exclude it from the commit. You can also double-click a file to
> see the diff.
Unfortunately, I don't have TortoiseSVN.
> Committing logically different changes separately is a good idea,
> but initially making those changes in a single working copy is not,
> especially if the changes occur to an overlapping set of files.
For two large logical sets, this is generally true. However, I find
myself in the following two situations several times a day:
- I have added printf() statements for debugging, and want to commit
the fix. The fastest way to do this is to do a commit, pick out all
the hunks that encompass the fix, and commit those. After that, a
'revert' cleans up the rest of the code. I cannot do a revert prior
to committing, because it erases the fix itself.
- I am working on a bigger change, and all of the sudden find out
some bug that needs fixing. Instead of doing a fresh checkout, re-
compile the whole project (which can take hours), fix the bug,
commit, erase the working copy, i can just work on my precompiled
working copy, fix the bug, and commit the small fix.
While these seem like very specific use cases, I think many people
face the same situations regularly as well (i know the people on my
project do, and this is why they refuse to move away from the
versioning system they currently use).
cheers,
Remko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 19 19:40:12 2006