Is there a way in svn to verify if an already existing file tree that "should" be at a given revision is in fact correct at that revision?

Suppose I had an earlier revision and obtains patches via svn diff for subsequent revisions, and applied them up to a given revision (or head). Now consider that perhaps some error happened during the application of these patches, or perhaps a file just got corrupted. What I would want to do is just verify if the tree I have now at this revision is the exactly tree I would get at this revision ... without actually pulling down the whole revision.

Note, I want to do this for exports, not for checkouts. That may make it simpler since the result of svn diff seems to only be for the actual data files.

doing that on an export is much harder as what you have locally is NOT SVN, they're just standard files so svn can not have any view about it at all. if it was a checkout then the "svn update" command does exactly what you want.

I understand that. What I'm looking for is something like how rsync works, but with a perspective of SVN. So could checksums work? All I need to do, per file, is to avoid the transfer of files I already have that are identical (if they are different, then the transfer is needed).

well maybe you should use rsync then. svnfs will let you mount a repo as a filesystem and then you can rsync on top of that, but exclude the .svn dirs.

Moved: This thread is more suitable in <Linux-Software> and has been moved accordingly to help your thread/question get the exposure it deserves.

Unfortunately, I don't have control over the SVN server. I have only read access to SVN and no other access to the machine at all. In fact, what I would download via SVN I was planning to re-export via rsync, anyway.

Think about that. Where would the checksum of the svn-hosted file come from? You'd retrieve the file and compute the checksum, then compute the local checksum, compare, and then if there's a difference you'd retrieve the file from svn again to overwrite the local copy. You've just retrieved the file at least once, and at most twice, per file in your local copy of the revision for which you are checking.

And what about those files that might have been deleted from your exported copy? How will you know that they exist in the revision and not locally? What about files added to your local export, but never imported into subversion? What if those files would have been handled by the svn exclude list?

I work with subversion every day for multiple projects. I am not claiming to be an expert, but I'm familiar with what we do. I have to ask, though, why spend so much time crafting a solution that is solved either with 'svn update' for a working copy or with 'svn export' for a clean (no .svn dirs)?

good luck!

I did think about that. That's why I was asking if there was a way to do it through the server, so the file would not have to be transferred. I was thinking about how rsync did it. What rsync does is compute the checksum at the server, and transmits just the checksum over the network, when the -c option is used. Unless -W is used, it transmits checksums of blocks of data, too.

Maybe the SVN server already has checksums cached and ready to use. Or maybe it's OK to have it recompute.

If the server sends a list of files, the clients detects a file not in the list and deletes it if the list was transmitted in sorted order or finished. There would be no files added in the normal sense, as this isn't a checkout.

To minimize network traffic.

I suppose if "svn update" really will minimize traffic, I might be able to live with the extra wasted space in a staging area and do a 2nd stage re-export via rsync with --exclide to take out .svn directories.

you don't need access to the server, svnfs is just a fuse filesystem and svn client.

How would it compute a checksum of a file without transferring that file over the network (avoiding this is the whole objective)?

I'm an idiot. Sorry, now I see what you were thinking about. I'm not aware of any way to get svn to send you a list of files and their checksums. Doesn't mean there isn't one, but if there is I don't know it.


Now that sounds like a pretty good solution! ;v)

The only way you might have a problem is for locally edited files in your working copy. 'svn update' won't revert those changes, but only bring up-to-date files changed on the server (committed) but at a lower revision in your checkout.

So, something like this?
then either
or your rsync excluding svn dirs. I like your way better.

well if you're rsyncing you'd have to make do with size and date really.

Unless the rsync daemon is running, no? Won't it help with calculating checksums on whatever machine is running the daemon?

well the point raised is that to get the checksum you'd need to read the whole file, and in the context of a mount of an svn repo would mean downloading the entire file each time.

Ah, yes. But I had thought that the poster was now suggesting to use svn update and then using rsync (excluding .svn dirs) to perform the equivalent of an 'svn export' on the local working copy.

So, svn to handle transferring on changes from svn, rsync to handle local working copy to rsync 'staging' area (if it is still necessary).

That is, of course, if I understood his suggestions correctly. ;v)