Digging up an ancient thread because I was recently asked if I ever got this to work.
2009/12/11, Nicolás Alvarez <[email protected]>: > http://boinc.berkeley.edu/trac/changeset/6540 > > Revisions 6540-6543 are weird. Log message shows they are from the > cvs2svn process. They seem to delete everything from trunk, which is > impossible: r6541 can't delete a file if r6540 already did exactly > that, and then how does r6544 edit the stuff that was deleted? This is totally wrong, I misread the Trac page. r6540 isn't deleting anything from trunk. It's copying trunk into branches/unlabeled-1.29.12, and then deleting things *in that branch*. The supposed inconsistency I mentioned (deleting things that were already deleted, etc) isn't there. Same in my reply message later: 2009/12/11, Nicolás Alvarez <[email protected]>: > I just tried "svn log" on the affected revisions. It shows > /branches/unlabeled-1.29.18/boinc/* being deleted, while Trac shows > trunk/boinc/* being deleted. Trac and svn log actually show the same thing, there is no problem here, I just misread Trac. > Trying to run svnsync on the BOINC repository halts at revision 6540 > with "svnsync: '/branches/unlabeled-1.29.12/boinc_papers' is out of > date". I'm pretty sure svnsync was working fine a few months ago. The real issue is with boinc_papers. If you look at trunk@6539, there seems to be no boinc_papers. But in fact there is, it's just server-side ACLs prevent me from seeing it. If I try to look at trunk/boinc_papers@6539, it asks me for authentication instead of saying "path non-existent in that revision". r6540 copied trunk into branches/unlabeled-1.29.12, then deleted a ton of things in the branch directory it just copied (this is pretty standard behavior of cvs2svn). Among others, it deletes branches/unlabeled-1.29.12/boinc_papers. When doing a full-repository svnsync, it doesn't ever see trunk/boinc_papers due to the ACL. When reaching 6540, svnsync copies trunk to branches/unlabeled-1.29.12, then tries to delete boinc_papers from the branch directory and fails because it's not there, because it never downloaded or even saw the existence of boinc_papers while syncing the previous revisions of the trunk. At this point it gives an error and aborts. A subversion developer confirmed that this is a bug in SVN. I worked around it with a nasty hack to the subversion source code so that if a deletion fails and the path ends in 'boinc_papers', it ignores the error and moves on. This allowed me to get past the problematic revisions, and now I can keep updating my local svnsync mirror using an unpatched SVN. If anybody else needs to do a svnsync of the BOINC repository, I could upload my copy somewhere, or at least the first few thousand revisions to get you past the problematic part. Again, there is no problem with the repository. The repository permissions on the server are fine too. It's a bug in SVN that makes svnsync fail with this particular authz setup. 2-year-late apologies for the false alarm :) -- Nicolás _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
