> > Committing logically different changes separately is a good idea,
> > but initially making those changes in a single working copy is not,
>
>I sympathize with the original poster. Sometimes while fixing one
>thing I get distracted with another thing that needs to be done
>first.
I find myself in that situation pretty often too.
> > The reason you might want that is if you had made two sets of
> > logically different changes in your working copy, and wanted to
> > commit them separately.
>
>What I do in this case is to create a diff of the working copy. Then
>with the magic of Emacs diff-mode I reverse the hunks of the diff that
>I want to remove and then apply them. As long as they are not in the
>same hunk I can effectively remove sections that I don't want to
>commit yet. Then after committing I can again reverse the diff and
>apply putting those changes back in.
I do something similar with TortoiseSVN. If I have only one or two
files with the logically different changes, I save backups of them
that contain all of my changes. I then start a commit with
TortoiseSVN, double click on those files to view the differences, and
revert ("use other text block") the specific changes I don't want to
commit yet. If I need to, I can run another test compile before
completing the commit. After committing, I restore the backup of
those files and commit again to pick up the changes that aren't
committed yet. That process works pretty well as long as I remember
to restore the backups and commit the changes from them.
If I have a lot of files with overlapping changes, I copy the entire
working copy (or at least the sub-tree that contains all of the
changed files) using the file system, not SVN's copy. I then start a
commit in each and revert all but the logically-related changes in
each. Finally, I delete one working copy and do an SVN update on the
other, which pulls in the other set of changes. The drawback to this
method is that if you revert a change in both working copies, you
loose it forever. One way to avoid that is to make a third
copy. Don't revert anything in it; just update it after committing
from each of the other copies. Anything you haven't checked in yet
should show up as a modification.
There is probably a way to do the equivalent of the above methods
using SVN branch/copy operations rather than file system copies, but
I am not familiar enough with it yet to say. I can see how
TortoiseSVN or any other SVN shell could automate the process
somewhat (it could even be a standalone checkin utility that could be
used in combination with any other SVN shell), but the pain of having
to sort such things out helps me be disciplined to not make such
overlapping changes :)
If you are half-way through making a set of changes and you need to
make an unrelated change before finishing, it is probably best to
check out another working copy (or keep one handy for such purposes),
make the changes there, commit, then update your original working
copy (the one that is half-finished) and continue. If you keep two
or more working copies relatively up to date, it shouldn't take long
to recompile them.
Steve
---
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:steve.strobel@link-comm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 6 15:19:30 2006