Re: Subversion Exception
On Jun 16, 2014, at 4:57 AM, Roy Umbach wrote: > Subversion reported the following What were you doing when that happened?
Re: TortoiseSVN bug - assertion failure
On Jun 13, 2014, at 7:00 PM, Ed wrote: > I don't know whether I'm sending this post to the correct address, as the > instructions for bug reporting are very poorly written. Do you have a suggestion for how the instructions could be improved?
Re: Subversion Exception
On Jun 18, 2014, at 4:16 AM, Roy Umbach wrote: > Doing an update to reflect the changes a colleague added ... When replying, you should reply to all, so that your message reaches the list too, not just me. I've re-added the list address to this reply so that the list gets your message and can hopefully assist you further. > > Met vriendelijke groet, > > Roy Umbach > Ontwikkelaar @ De Nieuwe Zaak > > Koggelaan 3c > 8017 JH > Zwolle > > Parkeeradres (navigatie): Hanzehoven, onze ingang is onder de passage > > t: 038 - 423 01 63 > e: r...@denieuwezaak.nl > w: www.denieuwezaak.nl > > Bekijk ook: www.ecmanager.nl - een krachtig platform voor webwinkeliers en > volg ons op www.twitter.com/denieuwezaak > > De Nieuwe Zaak – Thuis in e-Commerce > In de Emerce 100 gekozen tot het meest betrouwbare internetbureau > > > > 2014-06-18 10:44 GMT+02:00 Ryan Schmidt : > > On Jun 16, 2014, at 4:57 AM, Roy Umbach wrote: > > > Subversion reported the following > > What were you doing when that happened?
Re: problem: svnsync to external ISCSI drive increases size of repos
Also, repositories can be sharded, and complete shards can be packed, which can result in some space savings. Sharding is on by default now for new repositories, but packing must be done manually. So to answer your question, yes, there are a number of normal situations that could result in two repositories having the same contents but unequal sizes.
Moving a repository with svn:externals using absolute paths (URLs)
Hi, We’ve been using svn successfully for years on a server, and now have to migrate to a new one. We are hit by the known issue of svn:externals containing absolute paths to the repo to be moved, since we started with versions <1.5 without support for relative URLs. We’ve been researching how to properly do this, knowing that we handle certified SW on that server, so losing data or corrupting the repo is not allowed, and we want to be able to go back in time and checkout an old state at any time. We’ve experimented the svndumptool (http://svn.borg.ch/svndumptool/) referenced for instance in this post: http://stackoverflow.com/questions/204616/how-to-migrate-all-urls-in-svnexternals-properties-across-a-repository It seems to be the only tool doing what we want, and it apparently works, but before doing the change on the production repo we’d like to know what experiences there are with this tool, and if it’s safe to use – or if there is a better alternative. Thanks for your feedback if you have any experience with this, Nicolas AIRBUS HELICOPTERS DEUTSCHLAND GmbH Sitz der Gesellschaft / Registered Office: Donauwörth Registergericht / Registration Court: Amtsgericht Augsburg HRB 16508 Vorsitzender des Aufsichtsrates / Chairman of the Supervisory Board: Guillaume Faury Geschäftsführung / Board of Management: Dr. Wolfgang Schoder, Vorsitzender / CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt; Oliver Schenzle CONFIDENTIALITY NOTICE This communication and the information it contains is intended for the addressee ( s ) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful. If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much. It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message.
Re: Moving a repository with svn:externals using absolute paths (URLs)
On Wed, Jun 18, 2014 at 9:32 AM, Brisset, Nicolas < nicolas.bris...@airbus.com> wrote: > Hi, > > > > We’ve been using svn successfully for years on a server, and now have to > migrate to a new one. We are hit by the known issue of svn:externals > containing absolute paths to the repo to be moved, since we started with > versions <1.5 without support for relative URLs. > > We’ve been researching how to properly do this, knowing that we handle > certified SW on that server, so losing data or corrupting the repo is not > allowed, and we want to be able to go back in time and checkout an old > state at any time. > > > > We’ve experimented the svndumptool (http://svn.borg.ch/svndumptool/) > referenced for instance in this post: > > > http://stackoverflow.com/questions/204616/how-to-migrate-all-urls-in-svnexternals-properties-across-a-repository > > It seems to be the only tool doing what we want, and it apparently works, > but before doing the change on the production repo we’d like to know what > experiences there are with this tool, and if it’s safe to use – or if > there is a better alternative. > > > > Don't just take someone else's advice on it - test it with your own data. Dump your repository, process it with the tool, load it into a test server & make sure it all works the way you expect. Even if you get nothing but positive responses here, you should be doing this because there could be something unique with your data that causes breakage no one here has experienced.
Re: Moving a repository with svn:externals using absolute paths (URLs)
On Wed, Jun 18, 2014 at 9:32 AM, Brisset, Nicolas < nicolas.bris...@airbus.com> wrote: > Hi, > > > > We’ve been using svn successfully for years on a server, and now have to > migrate to a new one. We are hit by the known issue of svn:externals > containing absolute paths to the repo to be moved, since we started with > versions <1.5 without support for relative URLs. > > We’ve been researching how to properly do this, knowing that we handle > certified SW on that server, so losing data or corrupting the repo is not > allowed, and we want to be able to go back in time and checkout an old > state at any time. > > > > We’ve experimented the svndumptool (http://svn.borg.ch/svndumptool/) > referenced for instance in this post: > > > http://stackoverflow.com/questions/204616/how-to-migrate-all-urls-in-svnexternals-properties-across-a-repository > > It seems to be the only tool doing what we want, and it apparently works, > but before doing the change on the production repo we’d like to know what > experiences there are with this tool, and if it’s safe to use – or if > there is a better alternative. > > > > Thanks for your feedback if you have any experience with this, > > > > Nicolas > > The simple answer I'd recommend is "don't". The amount of time you are going to spend trying to cross migrate old build environments is expensive, fragile, and requires polluting your history to generate a new, and misleading one, pointing to the correct SVN server. Set aside the legacy configuration, incompatible as it is with modern "relative" URL's, for reference and log analysis only. Keep it pristine, and don't muck with the history. Bring only the relevant components to your new server, on a scheduled cutover date, and take the opportunity to discard bulky binaries and branches and logs and security sensitive debris with the move to a new server with a new URL. Drop a README.txt in place on the new server pointing to the old, legacy repository, and kick it aside. If your employers or clients cannot accept this, create migration branches, and tags as soon as you do the replication, with the safe new "svn:externals" settings. This is much safer than manipulating the old logs: once you get into manipulating logs, it's like cross-breeding puppies from the same litter: you may get the champion you want, but the practice can also lead to a lot disasters which will be blamed on the editing, even if it's not really the source of the problem.
RE: Moving a repository with svn:externals using absolute paths (URLs)
From: Nico Kadel-Garcia On Wed, Jun 18, 2014 at 9:32 AM, Brisset, Nicolas mailto:nicolas.bris...@airbus.com>> wrote: Hi, We've been using svn successfully for years on a server, and now have to migrate to a new one. We are hit by the known issue of svn:externals containing absolute paths to the repo to be moved, since we started with versions <1.5 without support for relative URLs. We've been researching how to properly do this, knowing that we handle certified SW on that server, so losing data or corrupting the repo is not allowed, and we want to be able to go back in time and checkout an old state at any time. We've experimented the svndumptool (http://svn.borg.ch/svndumptool/) referenced for instance in this post: http://stackoverflow.com/questions/204616/how-to-migrate-all-urls-in-svnexternals-properties-across-a-repository It seems to be the only tool doing what we want, and it apparently works, but before doing the change on the production repo we'd like to know what experiences there are with this tool, and if it's safe to use - or if there is a better alternative. Thanks for your feedback if you have any experience with this, Nicolas Hi Nicolas, We upgraded from 1.2 to 1.8 in one fell swoop. We don't use externals, which made things easier. However, most of our 1.2 repositories were in BDB format, which off-the-shelf Windows binaries of 1.8 don't handle. (I am somewhat averse to trying to recompile for Windows, as that would entail finding and setting up the correct compilation environment for it - too much like work.) I wrote a batch file to do a dump, reload and rename on each repository. Basically, the old repositories were left in place, but with the name changed to append "_BDB" and the re-loaded repositories in FSFS format run live. Full history now lives in both sets of repositories, with the BDB versions retained in case we ever need to go back and double-check. The simple answer I'd recommend is "don't". The amount of time you are going to spend trying to cross migrate old build environments is expensive, fragile, and requires polluting your history to generate a new, and misleading one, pointing to the correct SVN server. Set aside the legacy configuration, incompatible as it is with modern "relative" URL's, for reference and log analysis only. Keep it pristine, and don't muck with the history. Bring only the relevant components to your new server, on a scheduled cutover date, and take the opportunity to discard bulky binaries and branches and logs and security sensitive debris with the move to a new server with a new URL. Drop a README.txt in place on the new server pointing to the old, legacy repository, and kick it aside. This is basically what we did, but without mucking about to edit dump files, etc. As Nico says, keep the originals pristine. Disk space is cheap (although backup on alternative storage might not be). If your employers or clients cannot accept this, create migration branches, and tags as soon as you do the replication, with the safe new "svn:externals" settings. This is much safer than manipulating the old logs: once you get into manipulating logs, it's like cross-breeding puppies from the same litter: you may get the champion you want, but the practice can also lead to a lot disasters which will be blamed on the editing, even if it's not really the source of the problem. There's also the point that any editing you do is (a) prone to human error and (b) likely to consume large amounts of your time. In our duplication effort, we also set all the permissions on the old repositories to read-only, to limit the chances of cross-contamination. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
Re: Moving a repository with svn:externals using absolute paths (URLs)
On Wed, Jun 18, 2014 at 9:35 PM, Geoff Field wrote: > In our duplication effort, we also set all the permissions on the old > repositories to read-only, to limit the chances of cross-contamination. > > Regards, > > Geoff This. So much this. When people want to keep, and keep cross-merging, the contents of multiple distinct live repositories while work is being replicated and cross-merged from all of them, it's usually time to look for a new job: someone has been excited by the shiny tools and forgotten "source control is a 24x7, it must *work* and work *every time*" resource.
RE: Moving a repository with svn:externals using absolute paths (URLs)
> From: Nico Kadel-Garcia > On Wed, Jun 18, 2014 at 9:35 PM, Geoff Field wrote: > > > In our duplication effort, we also set all the permissions > > on the old repositories to read-only, to limit the chances > > of cross-contamination. Just to be clear, I'm not talking about the FILE permissions here, merely the SVN access permissions. To be really clear, the original repositories are only being kept as a paranoia measure, just in case our customers (or legal representatives) require unsullied history at some indefinite time in the future. > > Regards, > > > > Geoff > > This. So much this. When people want to keep, and keep > cross-merging, the contents of multiple distinct live > repositories while work is being replicated and cross-merged > from all of them, it's usually time to look for a new job: The vast majority of those repositories have been unused for some years, and our development team is (now) small enough so that I can guarantee there was no work proceeding on any of them. Naturally, I also shut down SubVersion while it was in progress, just in case. > someone has been excited by the shiny tools and forgotten Ooh, shiny ... What were we talking about? ;-) > "source control is a 24x7, it must *work* and work *every > time*" resource. Quite right. That's why our repositories are on a RAID system (now a SAN, actually) with regular backup (including off-site). Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
