60

I want subversion to commit a file even if it's unchanged. Is there a way to do this?

petr k.
  • 8,040
  • 7
  • 41
  • 52
pcorcoran
  • 7,894
  • 6
  • 28
  • 26
  • I assume there may be very rare situations where this is needed. But most of the time, it really should not be. Every revision in SVN contains a snapshot of every file in the repository. In a way, you DID commit your unchanged file in the last revision. You just committed no changes (because there were none). – Ben Nov 09 '14 at 12:47
  • 1
    One situation where this is necessary is when you've switched the _character encoding_ of an otherwise unchanged file. This goes undetected by (Tortoise, at least) SVN. – KlaymenDK Jan 19 '16 at 09:47

12 Answers12

72

If you want the file contents to remain unchanged (meaning that you can't merely change whitespace as johnstok suggested) you can always change one of the properties on the file.

eg.

svn propset dummyproperty 1 yourfile
svn commit yourfile

That will perform a commit without having to change the file.

Just make sure that you don't use one of the special svn: properties. Anything else should be ok.

Edit: A number of other posters have asked why someone would want to do this - presumably the people who have marked this answer down have also had the same concerns.

I can't speak for the original poster, but one scenario where I have seen this used is when attempting to automatically synchronise activities on a Visual Sourcesafe repository with a subversion repository.

Andrew Edgecombe
  • 39,594
  • 3
  • 35
  • 61
  • 1
    I don't buy that. Even in the context of VSS integration why would one need to force a re-commit of an unchanged file? – Chris Becke Oct 31 '08 at 12:23
  • 67
    @Chris Becke It really doesn't matter, does it? He has a need for it that others don't, apparently. We can either help him, or ignore the question. Some of the negative feedback I've seen here is ridiculous. – Chris Dec 21 '08 at 14:04
  • 3
    In 9 out of 10 cases (which I routinely round up to "always" :-)) cases, the questioneer has tried to solve a problem, done it badly, is left with a more problems than when he started, and is asking for help to put out the fire. – JesperE Dec 21 '08 at 17:56
  • I've seen this behavior several times on SO; the questioneer can for some reason not accept the most common answer ("XXX is not an option in this case") but does not explain why, and does not clarify the question when asked to. – JesperE Dec 21 '08 at 18:01
  • 20
    I'll give you a reason: some doofus checked in the file while his system clock was set far into the future. – Joshua Jan 25 '09 at 22:58
  • 14
    Use Case: A file (config, xml, etc.) is chosen as a canonical version beacon for other apps. It indicates that "the code queried represents version rXYZ in SVN". Using SVN's macros on commit ("$Rev: xxxxx $") would be ideal for these purposes, provided SVN would deign to update an unchanged file. – pcorcoran Apr 07 '09 at 04:33
  • my 2 cents: I got here because I use $Rev$ in my thesis.tex, which I never change because I \include all the sections. The SVN manual suggests to 'use svnversion plus some additional tooling' as part as my build process. I can certainly do that, I already use code to replace some other identifiers before compiling, but that kinda defeats the usefulness of $Rev$. Which is, that anyone else checking out my repo and compiles, will get a nice version number, on whatever platform. Using $Rev$ as text this is a hack anyway (it should be a comment), so I'm fine with just changing a space. – BlackShift Jan 15 '10 at 09:24
  • 1
    Which property exactly I could change without impact the project? http://stackoverflow.com/questions/2555711/svn-is-not-recognizing-the-changed-files – The Student Mar 31 '10 at 19:03
  • 2
    @Tom Brito: You can create any arbitrary property, so you're not restricted to the properties that are already in place. The only restriction is that subversion reserves properties starting with "svn:" for their own use. Other than that, and avoiding any properties specifically used in your project, you're free to create whatever you like. Take a look at "svn help propset" for some more details. – Andrew Edgecombe Apr 01 '10 at 01:58
  • 2
    Thanks for a good answer. Adding a new property is a great solution. As for use-cases: One may very well want to "fix" a bad comment without enabling revision property editing in the repository (because enabling it makes it easier to lose history). Adding a property to the relevant files and then committing again with a new comment is a helpful way to solve that issue. – Magnus Jan 11 '11 at 01:25
  • Often images aren't correctly recognised as changed by subversion. Hence the need to force the commit. – Sway Jul 04 '11 at 22:26
  • 1
    Another use case: I edited an image file with Photoshop, used Photoshop's Save for Web to re-save the file, clobbering the versioned one. Should have worked. TortoiseSVN didn't recognize the update and marked the file as current. There was no way, not even copy-and-paste that I was able to get TortoiseSVN to recognize that the file had changed. So the properties might be the only option - but does that really commit a new version of the file, or just change the props on it? – Tom Auger Aug 15 '12 at 20:53
  • 1
    O'Reilly uses SVN to manage book sources. If you forget to add "orm:commitpdf" to the check-in comments, a book is not built to inspect (O'Reilly scans comments looking for the directive). So its a valid use case: how do I check something in so I can make the "orm:commitpdf" comment to have the book built. I'm facing that situation right no (hence the reason I landed on this page). – jww Sep 29 '13 at 19:05
  • 1
    If you update a property, the revision changes but the file contents do not, and the file is not-re-uploaded. Considering SVN stores differences then this is exactly what you want - a new revnum that refers to the previous rev for the file contents. You cannot have a null delta, so this is the solution. – gbjbaanb Nov 14 '13 at 10:37
  • another reason to do a pseudo commit, is to test the hook scripts on the server side. – David Bonnin Mar 08 '16 at 09:19
  • This is perfect. My scenario is that I just need the server hook to run with some new comments. There was an initial checkin. Later I put some information into a "dummy" commit comment to be read by the server hook. The server hook updates a wiki. – Erik Olson May 05 '17 at 16:11
6

As to answer why one would like to do forced commits. I've seen cases where someone used a commit message that was wrong or unclear. It's nice if you can perform a forced commit, where you can correct this mistake. That way the updated commit message goes into the repository, so it won't get lost.

user253217
  • 69
  • 1
  • 1
  • Git has an easy way to amend commits. Doesn't svn have anything like that? That would be an easier and better way to fix wrong/misleading commit messages. – iconoclast Jul 06 '10 at 15:07
  • See http://stackoverflow.com/questions/304383/how-do-i-edit-a-commit-message-that-i-already-committed-in-subversion – Raphael Schweikert Feb 11 '11 at 16:51
  • 1
    Yes, you can edit commit messages in SVN, but that then applies to the full commit which may include numerous other files. Recommitting an unchanged file would still be useful when you want to provide a more clear commit message for a specific file which wouldn't be applicable to all of the files in the previous commit. – twm Oct 12 '14 at 16:13
4

I frigged this by deleting then re-adding the offending file. Not the nicest way to do it, and it probably broke the revision history, but it suited my purposes.

Reason for wanting to do it: File was one of two executables built from the same source (with different #defines set). Minor change to source meant one had changed, one didn't. I wanted to record in the revision history that I had actually updated it to the latest version (even though there was no change).

Maybe Morten Holdflod Møller's point that "the file will still be a part of the new revision" would cover this indication, but I think a log of the unchanged file did not show comments for that revision.

Mat
  • 82,161
  • 34
  • 89
  • 109
  • Changing the source gives you the opportunity to state exactly what you did, i.e. that "change X caused binary Y to be recompiled, but binary Z did not change". By forcing a commit when there really was no change to binary Z might actually confuse people: "why, if there was no change to binary Z, did he commit a new revision of it?" – JesperE Oct 16 '10 at 19:58
  • 1
    I use the TAGS directory for that. – ctrl-alt-delor Sep 27 '11 at 10:37
  • This is an ancient question and response, but I stumbled across it looking for something else so I want to point out that this WILL destroy all revisioning history for the file if you delete and re-ad it. Depending on what you are trying to accomplish there are probably better ways. – Bryan Shaw Aug 04 '15 at 17:35
2

If it's a text file just add some whitespace, such as a line feed.

johnstok
  • 96,212
  • 12
  • 54
  • 76
2

Answering some people questioning this should be possible: for some reason svn doesn't recognizes differences between doc files, so I would like to force commit as well!

I am now moving documentation from static dirs, to svn. files are like UG_v1.2, UG_v1.3 etc. So just to keep history, I take 1.2, remove version from the filename and add and commit it to svn. Then I take the ver from the second one, copy it over the first one and want to commit it and newer version. File size and creation date changes (not mentioning what's inside the doc), but svn claims it's perfectly the same file and disallows me to commit. When I manually change the doc, svn sees the different. The heck? :>

agata
  • 21
  • 1
0

I don't think that's possible, but first of all why do you need to do that? If a file is unchanged it shouldn't be commited.

If you really want that file grouped with other files in a commit you could change something minor inside (add a space for example).

rslite
  • 81,705
  • 4
  • 44
  • 47
  • 1
    O'Reilly uses SVN to manage book sources. If you forget to add "orm:commitpdf" to the check-in comments, a book is not built to inspect (O'Reilly scans comments looking for the directive). So its a valid use case: how do I check something in so I can make the "orm:commitpdf" comment to have the book built. I'm facing that situation right no (hence the reason I landed on this page). – jww Sep 29 '13 at 19:07
  • I see - in that case I guess a space added to the file will (should) not make a big difference and it would be easier than adding a property. By I would have used a property anyway for this, rather than the comment. Does this mean you have to remember to add this text every time you commit the file? – rslite Oct 05 '13 at 10:49
  • "Does this mean you have to remember to add this text every time you commit the file?" - Yes. – jww Oct 05 '13 at 17:19
  • "... in that case I guess a space added to the file will (should) not make a big difference and it would be easier" - Yes, the space appears easiest. Plus they use DocBook, so it harmless. – jww Oct 05 '13 at 17:20
0

The reason why someone wants to commit unchanged file is misunderstanding of how to revert to a previous version of a file.

For example, one may revert the file index.html in the revision 680 by just updating it to a revision in the past, e.g. 650:

svn update index.html -r 650

but it does not solve the problem, because:

svn status -u index.html
        *      650   index.html
Status against revision:    680

svn clearly says that index.html is modified remotely and you can't commit it, i.e. it "thinks" that index.html is old and should be updated to a newer revision. So the next svn update will bring index.html back to the revision 680.

To really revert a file you should merge it in reverse order:

svn merge -r 680:650 index.html

and then commit it svn ci -m "Reverted to r650" index.html

Sergiy Sokolenko
  • 5,967
  • 35
  • 37
  • 5
    Sergiy - someone may just want to commit something to trigger a hook on the server. Invoking the server's trigger has nothing to do with changing/reverting a file. – jww Sep 29 '13 at 19:12
0

Ancient question, but here's one reason why someone would want to do this:

We use an svn "commit" to document the successful outcome of a code review. During the code review, a certain subset of files is examined (and potentially modified). But files that are found to pass the review as-is will remain unmodified.

The idea is to use the commit to document which files were reviewed. That should include the ones that were found to pass the review without any modifications. Hence the need to "re-commit" ("force-commit") them unmodified.

endangered
  • 73
  • 1
  • 5
  • This would be a good example of why you would want to add a property to the file, maybe "Reviewed" which can be either "true" or "false". Then you could commit the files with only a property change. – JonS Jul 14 '23 at 22:30
-1

I have the same problem with a trueCrypt volume.

I added a new property (as suggested above) "forceCommit1" and them I was able to commit the volume file. but only the property was commited not the contents of the file.

I removed the file and added it again to the svn

user41806
  • 559
  • 4
  • 6
-1

Actually, I have come across a reason to do a force commit. This probably isn't best practice but we put Truecrypt (http://www.truecrypt.org/) volumes in SVN because we need to keep a tight security on some shell script as it contains sensitive information. When a Truecrypt volume is created, it's binary data stays the same no matter what you do with it. So in effect, I can change the contents of the volume but the volume never appears changed.

  • 4
    "When a Truecrypt volume is created, it's binary data stays the same no matter what you do with it." simply cannot be true. Either it's changed, or not. There is no magic involved. I'd recommend checking what you're actually trying to commit ;) – viraptor May 01 '09 at 23:04
  • See here for how to handle this with TC: http://www.flickspin.com/en/information_technology/truecrypt_svn_commit_issues – Nik Aug 03 '10 at 09:19
  • 1
    do you have a warehouse full of identical backup tapes? but with different dates on them. I would be worried about this. "something wrong somewhere!" – ctrl-alt-delor Sep 27 '11 at 10:36
-1

Changing the property will NOT force the commit.

TortoiseSVN 1.4.5, Build 10425 - 32 Bit , 2007/08/26 11:14:13

-2

I thought you could do it from the command line?

svn ci -force <filename>

I don't have a repository here to check that on, so I might be wrong.

endian
  • 4,234
  • 8
  • 34
  • 42