[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

SVNSYNC issues and queries

From: Wyper, James <james.wyper_at_landg.com>
Date: Mon, 25 Feb 2008 16:58:26 -0000

Hello, Some prelim info: Running subversion 1.46 with Apache https on a Wintel Platform. As part of a high availability proof of concept we have the following set up. Yet to go live by the way. We've clustered the subversion service by using 2 windows enterprise edition servers attached to the same piece of backend SAN. We keep the configuration on the SAN and have a separate Apache service on each cluster node which run in a mutually exclusive way. Whichever one is dominant prevents the other from gaining access to the SAN. The SAN itself is fully DR'd and snapped every 30 minutes. This works very well and I am very pleased with this solution. However: As part of the proof of concept I have been using svnsync to replicate existing subversion repositories. I want to be able to restore quickly (Not wait an hour for another team to pick up a request for restore) and I want to ensure that the copy we are making is true. In doing this I have hoped that svnsync will fail if it detects a corruption within the revision range it is syncing. Unfortunately this has not worked. After initialising the 2 repositories I made a few updates and ran the sync again and it worked just as it was supposed to. I then checked in a few more changes to the master repository and set about corrupting these new revisions. I did this in various ways: * By using a prop-set hook I incorrectly changed the date on the specified revision (not necessarily the HEAD revision). This is a very real problem we have experienced. svnadmin verify will return a Bogus Date statement and so will svn log. However unless this corruption is against the HEAD revision svnsync will work without error. * By going into the actual location where the subversion repository is located and opening either the revprops or revs folder and basically trashing a revision that has yet to be synched by changing the content of those revision files. Either changing the header information or by changing the source code stored there. Again unless I do this to the tip revision svnsync will work. * I did a few other things to corrupt the unsynced revisions but I think these were basically outside the remit of I would expect the sync tool to pick up anyway, such as deleting revision files. Again sync did not stop until after it had copied over the corruption. Svnadmin verify and svn log managed to pick up all these corruptions and either gave specific information or at least reported on the specific revision. Being on a wintel platform with multiple repositories and constant check over very large projects I am loath to have any post-commit verify run. And anyway I believe this would prove nothing as generally any corruptions do not happen at commit time but afterwards and the commit is in itself a form of verification. This though may be a presumption too far. Added to this we already do a verify every morning before start of play. My queries are. Is svnsync supposed to pick up these types of errors? Is this the wrong tool for the job? Am I doing something wrong in the svnsync process? Incidentally it is our requirement to have the correct timestamp on revisions that have not changed that leads the process for our post-revprop-change requirement. I believe this is something you guys are working on? As a software configuration manager who believes in the transparency of CM tools I find Subversion slightly invasive in this area. Regards. James. ********************************************************************** This email (and any attachments) may contain privileged and/or confidential information. If you are not the intended recipient please do not disclose, copy, distribute, disseminate or take any action in reliance on it. If you have received this message in error please reply and tell us and then delete it. Should you wish to communicate with us by email we cannot guarantee the security of any data outside our own computer systems. For the protection of Legal & General's systems and staff, incoming emails will be automatically scanned. Any information contained in this message may be subject to applicable terms and conditions and must not be construed as giving investment advice within or outside the United Kingdom. Legal & General Group plc is registered in England under company number 1417162 and is a holding company. The registered office for all companies in the Legal & General group is One Coleman Street London EC2R 5AA. The following subsidiary companies of Legal & General Group Plc are authorised and regulated by the Financial Services Authority: Legal & General Partnership Services Limited, Legal & General Insurance Limited, Legal & General Assurance Society Limited, Legal & General (Unit Trust Managers) Limited and Legal & General (Portfolio Management Services) Limited. Legal & General International (Ireland) is incorporated in Ireland under company number 440141 with its registered office at Alexandra House, The Sweepstakes, Ballsbridge, Dublin 4 and is authorised by the Financial Regulator in Ireland and by the Financial Services Authority for the conduct of insurance business in the UK. Full details can be found at http://www.legalandgeneralgroup.com/ **********************************************************************
Received on 2008-02-25 23:52:17 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.