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
parent.
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
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 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:
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
--
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ß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 <http://www.satorlaser.de/>
**************************************************************************************
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 werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte
Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht
verantwortlich.
**************************************************************************************
