tags:

views:

1318

answers:

6

Given the case I made two independent changes in one file: eg. added a new method and changed another method.

I often don't want to commit both changes as one commit, but as two independent commits.

On a git repository I would use the Interactive Mode of git-add(1) to split the hunk into smaller ones:

 git add --patch

What's the easiest way to do this with Subversion? (Maybe even using an Eclipse plug-in)

Update:
In The Thing About Git, Ryan calls it: “The Tangled Working Copy Problem.”

A: 

I used to do this:

  • In my editor (I use vim), edit the file so that only one of the changes appear
  • Save the file (but don't quit the editor)
  • Commit the changed file to svn
  • Hit "undo" in the editor enough times for the second set of changes reappear
  • Save the file again
  • Commit the second set of changes.

This is a simplistic approach that assumes one set of changes is reasonably easy to undo. For more complex situations, I would give up and commit both changes without worrying about it.

Now that I use git, this is something I hope I'll never have to do again!

Greg Hewgill
+5  A: 

I have done this using TortoiseSVN.

The built in merge utility allows you to show a diff between the reposotory version and your working copy.

Use the 'create backup' function of the diff utility

Step 1. Go to commit your file as if you were going to commit all your changes.

Step 2. In the commit window, double click the file to show a dif.

Step 3. In the diff settings, click the option to 'backup original file'.

Step 4. Right-click the changes you don't want, and use select 'use other text block'.

Step 5. Save the dif and commit the changes.

Step 6. Overwrite the original with the created .bak file (which will have all your original changes).

Step 7. Commit your file.

You should now have all your changes commited, using two seperate commits.

Spike
How exactly did you do this? I'd be interested in learning that technique.
Lasse V. Karlsen
TortoiseSVN is not available for Unix, right?
bene
Sorry, No. it's for windows
Spike
It would be so neat if this would automatically overwrite with the .bak files after a commit.
BCS
A: 

I use either a local darcs repo, or just merge the changes in gradually. With merging (opendiff opens FileMerge, a merge program that comes with Xcode; replace with your favorite merge tool):

cp file file.new
svn revert file
opendiff file.new file -merge file

merge the related changes, save the merge, quit the merge program

svn ci -m 'first hunk' file
mv file.new file
svn ci -m 'second hunk' file

if more than one unrelated hunk in the file, rinse and repeat (but why would you wait so long before committing?!)

Also, if you know git, you can use git-svn to maintain a local git repo and sync your commits to an svn master server; works great in my limited experience.

Aeon
Re: "Why wait so long?" Your doing a big all day refactor and the boss drops a little fix-this-now bug just before lunch.
BCS
+7  A: 

Try using svn diff > out.patch then copy the out.patch file to out.patch.add and out.patch.modify

Only when you have a working patch file revert the original file using svn revert out.c.

Edit the patch files by hand so that they only contain the hunks for adding or modifying. Apply them to the original file using the patch command, test if the addition worked, then svn commit the addition.

Wash rinse repeat for the out.patch.modify patch.

If the changes are separate in the file as your initial question stated - added a new method, changed an existing method - this will work

This is a very tedious solution - although I'm not convinced you should have any reason to separate your commits.

You also could have checked out multiple working copies of the same source to apply your work against:

svn co http://location/repository methodAdd

svn co http://location/repository methodModify

Be sure to svn up and test to make sure all is well.

Chris
+8  A: 

With git-svn you can make a local GIT repository of the remote SVN repository, work with it using the full GIT feature set (including partial commits) and then push it all back to the SVN repository.

git-svn (1)

jkramer
A: 
  1. Open all the files you want to split in editor-of-choice
  2. Using a different tool set (on Win, use Spike's suggestion (the old version)) back out the second set
  3. Commit
  4. go back to your editor-of-choice and save all the files

It's a little riskier than Spike's full suggestion but can be easier to do. Also make sure you try it on something else first as some editors will refuse to save over a file that has changed out from under them unless you reload that file (losing all your changes)

BCS