Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

the motherboard of a dedicated server I'm renting since five years went south and the motherboard got replaced by a new one. The very old (Debian) distro couldn't keep up with all the new hardware on the motherboard so I decided to re-install a new distro (Debian Wheezy) from scratch (even doing an upgrade was kinda problematic seen that the old Debian wouldn't recognize the ethernet chipset of the new motherboard as far as I can tell, so I went for a re-install from scratch).

I re-installed SVN and did get all the repositories by doing a:

tar -xzf repoBackups.tgz

And it "works".

The problem is that although, say, Eclipse recognizes the SVN repositories, it wants to commit every single file, even though they are identical.

Could this be related to timestamps on the files? Either way, do you have an idea as to what caused this and how to solve the issue?

I could simply ask everybody to re-commit every single file of every project and I think everything would be ok but some of these projects are quite big and it would be a bit painful for the developers.

As a bonus (and less important) question: would another VCS like Git or Mercurial not "suffer" from this problem?

share|improve this question
Which files to commit is a client-side decision, not server-side. And its done based on comparing the files with the cached copy in .svn (timestamps do not matter, AFAIK. At least, touch did not make it want to commit a file). What does the command-line tool say, e.g., when you run svn status ? – derobert May 1 '13 at 16:54
Does the same happen if you make a new checkout? – jofel May 1 '13 at 18:34
@derobert: (and jofel) : I don't have any old projects checked out on my system (I don't work on these, I just helped configure the server). The devs are remotely located, I'll ask them to try "svn status" (but they're not super experienced with SVN, nor am I, they simply use it from Eclipse). Good to know it's purely a client-side decision: it's weird because one dev told me he compared the files and they were identical, yet Eclipse / SVN wanted everything to be commited again. I'll have them "svn status" and report to me : ) – Cedric Martin May 1 '13 at 21:14
Any update? Did svn status yield anything interesting? How about svn diff? – derobert May 6 '13 at 21:14

Copying the files of a subversion repository is not a supported way of backing it up. (See [SVN]: How to backup repository? and what is the best way to backup subversion repositories? and How do I back up a remote SVN repository for proper methods.) It looks like the database has ended up in a corrupted state.

Try to run svnadmin dump on the untarred repository and svnadmin load on the resulting dump. This may result in a working repository (but no promises, I'm not very familiar with svn).

The timestamps on the files are irrelevant. Subversion doesn't use them to decide whether to commit, it uses revision numbers.

share|improve this answer
oh damn... Years of Git ended up corrupting me. I was 100% I could just tar all the SVN repos and that it was enough : ) Will try the svnadmin dump/load too. – Cedric Martin May 2 '13 at 2:51
If the repository is idle at the time, tar ought to work (though of course it'd be better to use the tools mentioned in the linked answers). – derobert May 2 '13 at 20:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.