top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

How to implement "selective checkout, merge and build use case"

+1 vote

We have a rather complex application with a large number of source files organized in folders where one folder-tree corresponds to one module. We're currently using SVN in order to version control and are looking at ways to use SVN for "selective checkout, merge and build" of selected modules. Each module has a specific setup of config-, documentation- and make-files making them "semi autonomous". When I say "semi autonomous" I refer to the fact that every module relies on one *core module* which provides the base functionality (foundation) needed by all the other modules.

The reason why we would like to be able to perform "selective checkout, merge and build" is that we need to be able to deliver a specific set-up of modules at a given time. That checkout would result in a checkout of the "core" module together with the other selected modules. After the checkout has been performed we'd like to be able to perform the following "post checkout" operations:

1. merge the modules config-fragments into a single config-file 

2. merge the modules doc-fragments (in Latex) into a single doc-file 

3. execute the modules make-files in order to build them 

Is there a recommended best practice to accomplish this using SVN or are there any complementing tools which could help us out here?

posted Jun 15, 2015 by Bob Wise

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

0 votes

Some people use svn:externals for this kind of thing, which can eventually turn into a disaster because it doesn't scale and only records relationships in one direction. You can't easily ask: "Which modules use a particular module M?" But you can ask "Which modules does module M depend on?" Since svn:externals use a set of segregated working copies they don't mix well with 'svn merge' -- you can't atomically merge a change set which affects multiple modules.
I've seen this approach both succeed and fail. Generally, I guess the more aware everyone is about the limitations of svn:externals the better it can be made to work.

If you really need this to scale over time and project size, you should consider a dependency management tool and leave the version control tool out of this. Unfortunately these tools tend to be very domain specific. For the Java world there's Maven, for embedded Linux there are several native package managers (rpm, deb, etc.), for Dotnet stuff there's NuGet, on Unix you have Makefiles... The best choice depends on your domain.

It sounds like you're already using make. Have you considered writing a Makefile which ties things together in a way you need and manages the dependencies? This may not be the answer you were looking for but it might keep things simple in the long term. You could take an intense look at how Linux and *BSD make-based build systems manage to target a wide variety of platforms from a single source tree to find some inspiration.

answer Jun 15, 2015 by Rameshwar
Similar Questions
+1 vote

With VisualSVN server version 2.1.4 (svn server version 1.6.13) When I try to checkout our project it throws an error message "svn: E175009: Missing update-report close tag". What could be the reason for this error message?
Can something could be corrupt in our server? If so is there any tool to verify and correct our repository?

+1 vote

We are using 1.6 SVN. We like to svn merge from our branch A to trunk.We have been diligent in svn merge from trunk to A.These svn merges from trunk to branch A also include --record-only merges too, in addition to regular merges. Development on branch A has stopped.Now we like to merge branch A to trunk using --reintegrate option.B ut we dont know what to expect if using this option fails on us.

1) Suppose svn merge --reintegrate fails on us on a working copy that has all the mergeinfo list information. Could we perform a clean co of branch A into another working copy and then perform svn merge --reintegrate to trunk there ? Will we get more conflicts simply because the new working copy doesnt have the mergeinfo list like the first working copy of branch A ? Will this plan B work ?

2) How do we resolve conflicts during svn merge --reintegrate process ? Would you share the steps for us to make the merge go smoothly ?

3) Is mergeinfo a global or local property ? it seems that whenever a new checkout is done, mergeinfo list matches up with other working copies of the same branch.

+1 vote

In attempts to build the gomp_4.0 branch from svn (on CentOS 6.2), I find that I must remove the -Werror option in STRICT_WARN. I don't find documented how this should be done (in configure ?). I can get past it by repeatedly modifying gcc/Makefile, but this seems wrong.
I have little interest at this stage in finding out why it triggers -Werror=maybe-uninitialized in typeck.c; I'd only like to build the gcc to see if it does anything interesting with OpenMP 4.

+5 votes

Are there side effects from applying the same svn merge --record-only on the same revision number and a new commit each time it is applied ?

Would there be issues with SVN mergeinfo and/or SVN in general if one keeps applying svn merge --record-only on a revision number repeatedly and commit in a svn merge --record-only followed by commit followed by svn merge --record-only followed by commit and the next cycle begins ? Its not an infinite loop svn merge; it would stop at some point.

+2 votes

While merging branch back to trunk I constantly get the error in the subject. Note that x/y/z has svn:mergeinfo property. The property was not added on the branch, but it was already there when the branch was created. Subsequently x/y/z is deleted on branch.

The error is generated when running: "svn merge ^/branches/mybranch" on a trunk working copy.

Sounds to me like a bug, svn tries to update the mergeinfo on the deleted path. Is that so ?