48
votes

I'd like to commit just a part of a file using TortoiseSVN, is there some way to do that?

I'll give an example to make it clearer why I want to do that.

I have a file with some defines that are replaced in the build process, something like this:

#define SOME_PATH "[SOME_PATH]"

This [SOME_PATH] tag is replaced in the build process but when I'm coding I have to change it so the actual path in my machine.

So each time I commit I need to backup some lines, revert them, commit and then restore the backup, and this is kinda annoying.

Is there some way to tell TortoiseSVN to "ignore" some changes in, say, Lines X,Y and Z?

8

8 Answers

74
votes

The top voted answer is out-of-date.

From the tortoiseSVN website: http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-commit.html

Commit only parts of files

Sometimes you want to only commit parts of the changes you made to a file. Such a situation usually happens when you're working on something but then an urgent fix needs to be committed, and that fix happens to be in the same file you're working on.

right click on the file and use Context Menu → Restore after commit. This will create a copy of the file as it is. Then you can edit the file, e.g. in TortoiseMerge and undo all the changes you don't want to commit. After saving those changes you can commit the file.

After the commit is done, the copy of the file is restored automatically, and you have the file with all your modifications that were not committed back.

12
votes

No. Subversion works at the file level.

7
votes

No.

The best way to do that is to check in some file like "build_paths.h.default", then on each build platform, copy it to build_paths.h, modify it to suit, then tell SVN to IGNORE build_paths.h. And finally #include "buiild_paths.h" within your program.

6
votes

In general yes! Functionality has been added in the latest version of torroise svn (1.8) See release notes Unfortunately it's a manual process that may well not be so suited to your specific use case - more useful for "I'm in the middle of a new feature and have noticed a bug and want to commit just the bug fix" situation.

For your situation I use a template file which is used in the build process to create the actual file used (this file is only created from the template file, nothing else is present). I have the tempalte file in svn but the acutal file ignored. THis means I only need to build once after a new checkout and then my working copy is OK - but the values for the tags are not committed. If I need to add new tags I do so in the tempalte file and rebuild my working copy.

4
votes

Short version: NO. Subversion is an all-or-nothing system (as are all source control systems I know of)

Longer version: No, however if you use something like NANT to do you build, you could use xmlpoke or similar to rewrite parts of the file on build. Works for us :) We rewrite about 6 web.config files and various other app configuration files on build (well, on building a deployment package)....

4
votes

The solution to your problem is not to get subversion to do this for you, but to configure your application so that environment specific details (Such as the [SOME_PATH] value) are stored 'externally' to the code that is checked in.

Whether you do this via a separate file that is marked to be ignored by SVN, or whether you store this information in an environment variable, depends on your development language/OS and a few other factors.

Whichever solution you use, it may be wise to arrange some kind of default, to allow for the case where no value is specified.

It may also be worth considering whether the details should be applied at build time or run time - if you can arrange the latter, it makes deployment of new versions of the application much easier.

A typical example is found in web applications, where a database connection is required, but the actual database instance to be used is different between development and production environments. In such cases, the database configuration is defined on the web server (Not in the application, which simply asks the web server for a database connection with a given name) with development and production servers having different configurations. It is then possible to deploy the same web application to both servers and have each app instance access the appropriate database.

2
votes

You could also define :

  • a pre-commit hook which will take care of the rollback for you,
  • and a post-commit hook to restore your file.

Ouch... actually this is not a good idea, according to the SVN Manual.

  • All triggers are executed on the server side (not the client side, as it is the case for ClearCase)
  • Subversion keeps client-side caches of certain bits of repository data, and if you change a commit transaction in this way, those caches become undetectably stale. This inconsistency can lead to surprising and unexpected behavior. Instead of modifying the transaction, you should simply validate the transaction in the pre-commit hook and reject the commit if it does not meet the desired requirements

A possible way would be to modify your file in a post-commit script, and then commit that file as an independent change, before restoring it in another post-commit script...

0
votes

What you are looking for is a feature of various distributed version-control systems such as darcs.