subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Eckhardt <>
Subject Re: swapping the trunk and a branch
Date Thu, 08 Jul 2010 15:39:03 GMT
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 can 
be "svn:mergeinfo" properties, but when a file or directory has an empty 
svn:mergeinfo property, its merge tracking info is implicitly that of its 

Annoyingly, if you manually set it on a single file once (e.g. by only merging 
a single change to that file), it remains there. If you now merge to its 
parent directory, the file's "svn:mergeinfo" property is updated, too, even 
if it is not touched in the merge operation.

Other than that, what Les Mikesell said might be true, i.e. that you need to 
dump/reload your repository in order to reap the benefits of newer server 
versions. I seem to remember some features concerning merge tracking coming 
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 
old versions, just so we could relatively easy switch back in case we found 
problems coming from the new build system. Other than that, we mostly let 
those rot, they were not on a high priority but only handy for a limited 

> 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 separate, 
too. That means that even if you have them in a common solution dir when you 
work on them, they are separate things as far as their placement in the 
repository is concerned and that they have separate merge info. However, 
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 
solution dir. You can then "svn switch" it to different targets, e.g. to 
various released version or an experimental one. In any case, it would become 
a separate project as mentioned above. The empty dir (or file) would then 
only serve as a placeholder or reminder. It's a one-time manual setup 
operation you will have to educate your colleagues about though.

> The other "fix" I've 
> 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 compiled 
there, too? Anyway, I don't see why externals are evil. They present some 
complexity that you must learn to control, but not really that much IMHO. In 
any way, what we have here is like this:


I.e. the different binaries are not an either-or thing but can coexist.



Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
           Visit our website at <>
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und
kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend,
falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu
löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen
enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.

View raw message