From users-return-3603-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org Thu Jul 08 15:43:34 2010 Return-Path: Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: (qmail 58867 invoked from network); 8 Jul 2010 15:43:34 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 8 Jul 2010 15:43:34 -0000 Received: (qmail 14408 invoked by uid 500); 8 Jul 2010 15:43:33 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 14319 invoked by uid 500); 8 Jul 2010 15:43:32 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 14149 invoked by uid 99); 8 Jul 2010 15:43:32 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Jul 2010 15:43:32 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=SPF_PASS,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [64.212.99.82] (HELO uk-hc-ps3.domino-printing.com) (64.212.99.82) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Jul 2010 15:43:26 +0000 Received: from emea-exchange3.emea.dps.local (emea-exchange3.emea.dps.local) by uk-hc-ps3.domino-printing.com (Clearswift SMTPRS 5.3.4) with ESMTP id for ; Thu, 8 Jul 2010 16:40:05 +0100 Received: from tuxator2.emea.dps.local ([192.168.55.75]) by emea-exchange3.emea.dps.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jul 2010 17:39:04 +0200 From: Ulrich Eckhardt Reply-To: users@subversion.apache.org Organization: Sator Laser GmbH To: users@subversion.apache.org Subject: Re: swapping the trunk and a branch Date: Thu, 8 Jul 2010 17:39:03 +0200 User-Agent: KMail/1.9.9 References: <4C3496DD.1080006@codeware.com> <201007081059.09466.eckhardt@satorlaser.com> <4C35E265.7040204@codeware.com> In-Reply-To: <4C35E265.7040204@codeware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201007081739.03452.eckhardt@satorlaser.com> X-OriginalArrivalTime: 08 Jul 2010 15:39:05.0105 (UTC) FILETIME=[B263B810:01CB1EB3] X-Virus-Checked: Checked by ClamAV on apache.org On Thursday 08 July 2010, Cory Riddell wrote: > On 7/8/2010 3:59 AM, Ulrich Eckhardt wrote: > > Of course, the complexity (i.e. memory and time) for a merge operation > > increases with the number of revisions and the number of files, but a > > mere VS upgrade should only touch projectfiles and maybe a few > > sourcefiles, all of which are easy to merge and not too large. > > The repository has history going back more than 10 years. Lots of > revisions. The VS upgrade really didn't alter the contents of very many > files. I'm thinking the problem is coming from merging trunk->branch. This > seems to touch the properties of every single file in the repository and > I'm speculating that's what is eating up 8 GB of memory. If I understand > this correctly, subversion is adding metadata so it knows what revisions = to > merge next time I push changes from my trunk to branch. Yes and no. SVN does attach merge tracking info to the working copy. This c= an=20 be "svn:mergeinfo" properties, but when a file or directory has an empty=20 svn:mergeinfo property, its merge tracking info is implicitly that of its=20 parent. Annoyingly, if you manually set it on a single file once (e.g. by only merg= ing=20 a single change to that file), it remains there. If you now merge to its=20 parent directory, the file's "svn:mergeinfo" property is updated, too, even= =20 if it is not touched in the merge operation. Other than that, what Les Mikesell said might be true, i.e. that you need t= o=20 dump/reload your repository in order to reap the benefits of newer server=20 versions. I seem to remember some features concerning merge tracking coming= =20 in with version 1.5 or 1.4.... > > That said, what we have here is sourcecode that compiles in parallel on > > VC6, VC7.1, VC8 and eVC4. All you have to take care of is that the > > directories for output and intermediate files (OutDir and IntDir) have = an > > according tag so that they don't interfere with each other. That's > > completely off-topic for this list though... > > It's offtopic, but still interesting to me. If I had to maintain > multiple versions of the project files, I would probably start looking > at something like CMake to generate the project and solution files. > Without that, it seems very error prone to have to remember to update > each version of the project file with every change. Well, maintain in parallel is a bit overrating. Rather, we tried to support= =20 old versions, just so we could relatively easy switch back in case we found= =20 problems coming from the new build system. Other than that, we mostly let=20 those rot, they were not on a high priority but only handy for a limited=20 time. > My other problem is that our project relies on a rather large third > party library. We have the include and lib files as a subproject living > under the solution dir. I don't want the merge to recurse into this one > directory: > + Main Solution Dir > - sub project 1 > - sub project 2 > - 3rd party project If those projects are separate, I would say you should treat them as separa= te,=20 too. That means that even if you have them in a common solution dir when yo= u=20 work on them, they are separate things as far as their placement in the=20 repository is concerned and that they have separate merge info. However,=20 opinions vary there. > I've thought about moving the 3rd party project directory to a different > place in the repository and using an external directive, but I'm really > trying to avoid using them. They're evil, right? There is one other way, and that is to simply put an empty folder into your= =20 solution dir. You can then "svn switch" it to different targets, e.g. to=20 various released version or an experimental one. In any case, it would beco= me=20 a separate project as mentioned above. The empty dir (or file) would then=20 only serve as a placeholder or reminder. It's a one-time manual setup=20 operation you will have to educate your colleagues about though. > The other "fix" I've=20 > thought about is having multiple 3rd party projects. > + Main Solution Dir > - sub project 1 > - sub project 2 > - 3rd party project VS2008 > - 3rd party project VS2010 I'm not sure I understand. Are those binary-only projects or are they compi= led=20 there, too? Anyway, I don't see why externals are evil. They present some=20 complexity that you must learn to control, but not really that much IMHO. I= n=20 any way, what we have here is like this: project /include /lib-vc6 project.lib /lib-vc8 project.lib I.e. the different binaries are not an either-or thing but can coexist. Uli --=20 ML: http://subversion.tigris.org/mailing-list-guidelines.html FAQ: http://subversion.tigris.org/faq.html Docs: http://svnbook.red-bean.com/ Sator Laser GmbH, Fangdieckstra=DFe 75a, 22547 Hamburg, Deutschland Gesch=E4ftsf=FChrer: Thorsten F=F6cking, Amtsgericht Hamburg HR B62 932 ***************************************************************************= *********** Sator Laser GmbH, Fangdieckstra=DFe 75a, 22547 Hamburg, Deutschland Gesch=E4ftsf=FChrer: Thorsten F=F6cking, Amtsgericht Hamburg HR B62 932 ***************************************************************************= *********** Visit our website at ***************************************************************************= *********** Diese E-Mail einschlie=DFlich s=E4mtlicher Anh=E4nge ist nur f=FCr den Adre= ssaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benach= richtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf= =E4nger sein sollten. Die E-Mail ist in diesem Fall zu l=F6schen und darf w= eder gelesen, weitergeleitet, ver=F6ffentlicht oder anderweitig benutzt wer= den. E-Mails k=F6nnen durch Dritte gelesen werden und Viren sowie nichtautorisie= rte =C4nderungen enthalten. Sator Laser GmbH ist f=FCr diese Folgen nicht v= erantwortlich. ***************************************************************************= ***********