Did you know … that you can have more than one working copy corresponding to a repository URL? In that way, you can have two sets of changes as if you’re two engineers. This is useful if you have local modifications for two different features or fixes, and you wish to commit them separately.
This is possible because with SVN (Subversion), the working copy points to the repository, rather than vice versa.
To manage changes in two (or more) working copies, you will usually need to update each of them after committing to either/any of them. You may need to resolve conflicts when updating, even when both set of changes (the local modifications in your “current” working copy and those committed from another of your working copies) are your own.
Suppose that you have a single working copy, in which you have been working on a new feature. Whilst doing that, you have found some bugs in the pre-existing code, which you’ve fixed; you’ve updated a couple of copyright messages that you noticed were out of date; you’ve also added a few comments to the pre-existing code. Really, these sets of changes should be committed separately. If you’re very lucky, the sets of files associated with each of the functional changes are disjoint. [Then, you could even make use of the “changelist” feature of SVN 1.5 (client-only) to help manage this.]
In all probability though, that is not the case, and some of your files contain modifications for more than one functional change. If you’re really unlucky, you may even have different modifications for more than one functional change on individual lines within some of your files.
What you can do is open a new, second working copy “wc2” alongside your existing one “wc”, and, one by one, copy across changes, perhaps with the help of a differencing tool such as WinMerge or Beyond Compare. You commit from wc2, and then update both wc and wc2. You may need to resolve conflicts in wc. That should only happen where individual line had more than one modification, or perhaps where neighbouring lines had changes.
You can also use such “secondary” working copies to generate ‘special’ builds, without disturbing other local modifications you might be working on. For example, you could have one working copy updated to revision 1234, and then merge a later change made at revision 1300 and/or “unmerge” (i.e. merge the reverse modification) a change made back at revision 1199, perhaps to test a theory about a bug.