Subversion: stage files to commit explicitly?

I got very used to git‘s way of having to touch every file you want to commit, and, while at it, double-check the diff. Now at work i have to use svn and i keep commiting stuff accidentially. Is there a way to make subversion behave like git in that i have to tell every file explicitly that should be included in the next commit?

  • How do I edit past git commits to remove my password from the commit logs?
  • Does Gitorious have hooks for CIA commit notification?
  • Git default merge commit message not including conflicts
  • Moving all commits beyond initial commit off master
  • Commit file from Jenkins workspace to SVN
  • Git says local branch is ahead of remote after having pulled from remote
  • Using NODE_PATH with Git submodules
  • Do git tags get pushed as well?
  • commit is not accessible using TortoiseGit Daemon
  • Decoding git objects / “Block length does not match with its complement” error
  • Difference between git pull --rebase, git rebase and git merge
  • Troubles with git and Gemfile.lock
  • 6 Solutions collect form web for “Subversion: stage files to commit explicitly?”

    An alternative method would be to use the git-svn bridge at work, unless there are reasons as to why you can’t. No one but you will have to know that you’re actually using Git. This way you get all the benefits of Git while actually using Subversion.

    Specify the files on the command line

    svn commit -m “My commit message” folder/file1.c

    You could create a changeset that lists only the files you want to commit and then commit the changeset. If you’re diligent about deleting changesets when you’re done with them and never commit without a changeset, I think that would work for you. The easier solution would be to use a graphical client (such as TortoiseSVN, but there are others for all platforms with similar functionality) which shows you a list of the files that are going to be committed at the time it prompts for your login message. Then if you click “Commit” without reviewing them, it’s not because it didn’t tell you what it’s going to do 🙂

    To follow on Rory’s answer, if you want to enforce explicit file commit behavior, you could write a batch or shell script that checked to make sure you had at least one argument other than the commit message and returned an error if you didn’t. That would at least give you a reminder to explicitly put the file names in.

    I always do an svn stat and diff before committing anyway, so the stat usually reminds me that there may be things that I didn’t want to check in just yet.

    I usually commit from some IDE, like Emacs, where I can manually choose set of files to commit.

    Subversion works the way you want by default. Add items that are added, deleted, or modified are staged and are not committed until you use the commit command in which you specify the files you want to commit. If you are using the command line and just running “svn commit” without any other parameters then I can see what your problem might be and in that case I would use the changeset feature that others have suggested and also use commit time as a self code-review time to glance at all of the changes and decide which go in and which do not.

    I would also add that it is a bad habit to only do partial commits and should only be done when you are very conscious of what you are doing if you are in a shared branch as it is one of the most common ways to break a build do to unexpectedly interrelated changes not being included within the same commit.

    What I do and recommend to others in the case where I have changes that I want to commit separately is to create a patch or a set of patches for the changes I’m not interested in committing at the time and then revert those same files from my working copy. Now that the working copy only has the changes I’m going to commit I’ll rebuild and verify correctness by either doing manual testing or unit tests and then only when all of these pass do a self code review and commit. I think this way is the safest way to interact with a large group especially when you are making complex changes. This process could also be made easier of svn was to support a client-side shelving feature to put changes into a temporary store with a name similar to a changeset via a single command.

    Also BTW, using TortoiseSVN makes it a lot easier to manage changesets and cherry picking files that will go into any given commit. If your on Windows I highly recommend checking it out for that reason.

    Git Baby is a git and github fan, let's start git clone.