I want subversion to commit a file even if it's unchanged. Is there a way to do this?
A:
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
2008-10-15 20:06:39
A:
if you check out a project you can commit it. If nothing has changed it doesn't update the revision number or the files.
J.J.
2008-10-15 20:08:05
+2
A:
If it's a text file just add some whitespace, such as a line feed.
johnstok
2008-10-15 20:10:35
+25
A:
You can't, and you shouldn't. You should also thank Subversion that it refuses.
Now, what problem are you really trying to solve?
JesperE
2008-10-15 20:35:58
Curiously, this answer has gotten a large number of both up and down-votes, yet nobody has bothered to comment on it.
JesperE
2010-09-12 16:43:18
one reason this has come up for me was that I had replaced an image file, and for some reason SVN could not tell it was changed, so I had to do this to force it through. Though I agree, in most cases this isn't nessecary.
GSto
2010-09-23 16:29:25
-1 for "your going to do it this way, and your going to like it."
tster
2010-10-16 01:49:38
@GSto: if SVN fails to recognize that the image file has changed, I would recommend that you investigate the cause of that. By forcing a commit, you are just masking a possibly more serious problem you have. If you really have changed the image file, SVN will recognize it. Otherwise, you have a bug in SVN.
JesperE
2010-10-16 18:43:08
@tster: Yup. When people ask questions without providing any more context as to why, then this is the answer I will give them. I know that I will get downvotes on it, but I refuse to help people do something I think is wrong without knowing why.
JesperE
2010-10-16 18:44:43
@JasperE, I didn't downvote because of the content, I did it because of the tone.
tster
2010-10-17 14:45:03
Well, sometimes I sound a little rude when I think people ask silly questions. And it turns out that he didn't *really* want to commit an unchanged file, he rather wanted to force a keyword expansion on an unchanged file. He would've gotten much better answers if he said that from the beginning. (This is a typical case of the very common pattern, especially here on Stackoverflow: I have problem X which I want to solve by doing Y. How do I do Y? My answer: You shouldn't do Y, because Y is the wrong solution to X.)
JesperE
2010-10-17 21:56:21
+4
A:
It does not really make much sense... :)
For at least two reasons:
- The file will still be a part of the new revision even if there were no changes to it.
- Subversion only stores the differences between the files in the two revisions. If the files are identical what would be stored?
Why would you want to do this? What are you trying to do?
Morten Holdflod Møller
2008-10-15 21:10:59
+13
A:
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
2008-10-15 23:04:17
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
2008-10-31 12:23:43
@Chris BeckeIt 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
2008-12-21 14:04:17
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
2008-12-21 17:56:55
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
2008-12-21 18:01:57
I'll give you a reason: some doofus checked in the file while his system clock was set far into the future.
Joshua
2009-01-25 22:58:13
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
2009-04-07 04:33:10
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
2010-01-15 09:24:00
Which property exactly I could change without impact the project? http://stackoverflow.com/questions/2555711/svn-is-not-recognizing-the-changed-files
Tom Brito
2010-03-31 19:03:50
@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
2010-04-01 01:58:03
A:
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
2008-10-31 10:31:18
+1
A:
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
2008-12-21 13:02:14
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
2010-10-16 19:58:30
A:
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.
"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
2009-05-01 23:04:22
See here for how to handle this with TC: http://www.flickspin.com/en/information_technology/truecrypt_svn_commit_issues
Nik
2010-08-03 09:19:34
A:
Another reason to have forced commits (at least for conflicting or not up to date files).
I use one version control system (w/ repository in a remote server). This one is the main and used by the team. And I installed SVN to use locally for the same projects.
I want to use SVN to, in short, 1. force commit all the files to have save current state with my changes ready for the central repository; 2. experiment (for example by applying other algorithms in the code), commit my local changes to SVN, keep track of those changes; 3. then, be able to revert all or some of my saved state if necessary.
It doesn't make sense to create new SVN repository for every experiment.
After working a while on the code without sync-ing with SVN I can see many missing/conflicting or "not up to date" files. Those are the problem. It doesn't make sense to resolve conflicts one by one here. I just want force commit.
resak
2009-07-30 21:37:18
it looks like a case where git would fit better (as everything is local too).
gpilotino
2009-11-01 23:09:31
A:
I want to mark code to belong to a particular Jira ticket, code is connected to a Jira ticket via a comment made on that piece of code. Can you comment on code that's not being checked in?
LJones
2009-11-01 23:04:23
@LJones, if you have a question you want answered, click on the "Ask a Question" button at the top of every page.
nickf
2009-11-01 23:14:12
+1
A:
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.
A:
Hey guys,
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
2010-03-04 13:27:20