On Mon, Feb 25, 2008 at 8:58 AM, Wyper, James <james.wyper_at_landg.com> wrote:
>
>
>
> 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.
svnsync copies over revisions, including the given "svn:date"
property. Other tools can verify that the value found is valid.
> 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.
Really? You're saying you can trash an unsynced revision, but then
sync it successfully? This is rather surprising.
Anyway, I'm not sure that it's svnsync's job to verify any data other
than the data that it needs to read to replay the revision. svnadmin
verify (which has just gotten some improvements for FSFS) is more
appropriate here.
--dave
> 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/
>
> **********************************************************************
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-26 22:26:31 CET