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