Re: How to combine files from different svn locations into a working copy?§

On Jan 2, 2018, at 11:31 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>
>> On Tue, Jan 2, 2018 at 4:38 PM, Bo Berglund <bo.berglund_at_gmail.com> wrote:
>> On Sat, 09 Dec 2017 18:02:20 +0100, Bo Berglund
>> <bo.berglund_at_gmail.com> wrote:
>>> vProject
>>> |--- src (all sources from the physical project module)
>>> |--- bin (the binary output from the project)
>>> |--- cmn (selected files from a "Common" project module)
>>> |--- lib (maybe some selected binaries needed by the project)
>>
>> So I have found that using externals in the "normal" projects sort of
>> solves my main problem of including library and common files into
>> different real projects.
>> However I have now run into a slightly different problem:
>> When I declare the external I have not found a way to limit the depth
>> of recursion such that only the top directory of the external gets
>> checked out..
>>
>> I use an open-source library in several projects and it contains a doc
>> subdirectory with essentially a website of html and image files. I
>> don't want these 77 files to be checked out as externals if I can
>> avoid it, but limit to the 8-10 source files in the top level code
>> directory.
>>
>> Can this be done using some externals flag?
>
> No, I'm afraid that's not possible at the moment. See
> https://issues.apache.org/jira/browse/SVN-3216.
>
> --
> Johan

We developed an internal library which is used by several programs. The library and the programs are all in a single repository, and each is treated as its own self-contained project, meaning they each have their own trunk/branches/tags, their own version number (not to be confused with svn revision numbers), their own release cycle, etc. We use externals to get the library sources into the working copy of the program sources, much like you describe. And we avoid pulling in docs and other non-source files:

The program src directory contains a subdirectory called Externals. On this subdirectory we set the svn:externals property to get all dependencies. Each dependency ends up in its own subdirectory of Externals.

To solve the same issue you're having now, which is to avoid checking out potentially a lot of unnecessary data like docs, etc., we structured the library project to keep all its sources in a src directory; so we have for example:

Library
Library/trunk
Library/trunk/src
Library/trunk/doc
etc.

In our externals property we fetch only that src directory, and we call the working copy, say, Library (or whatever the name of the library is):

Program
Program/trunk
Program/trunk/Externals
Program/trunk/Externals/Library

Since the library you're using comes from a third party and is tracked in your repo, you should see the svn-book section on vendor drops (sorry, I don't have the link handy). Contrary to what the book suggests, I would probably keep the vendor's original distribution separate from our internal customizations, treating them like two different branches (because that's essentially what they are). The first such customization would be to move the sources into a src subdirectory, so we could external it like I described above. Perhaps others have better ideas.

Not sure if others mentioned this (in fact I'm not even sure if I mentioned it) but here are a couple of additional externals-related suggestions:

In the externals property, we use the caret notation '^' which tells svn that the external URL is relative to the repository root. This is because (1) they are in the same repository anyway and (2) we avoid using an absolute URL to avoid future breakage should we move the repository to a different address in the future.

Furthermore even though we are generally fetching a tag (that is, a specific tagged release of our library), we use the '@' notation to fetch the tag in the specific revision where it was created. The reason for this is subtle but important: suppose someone later commits to the tag directory of the library, and suppose that in the future we check out today's revision of the program that uses that tagged version of the library; we want that future checkout to look identical to today's checkout. The '@' notation guarantees that. It also gives us the option, instead of using a tag, to use a specific trunk revision of the library without worrying that the library will change without the program devs knowing. I think that's sometimes done when they hack on both at the same time.

By structuring our repo this way, the library can be developed independently without fear of rippling effects through dependent programs, and the dependent programs can choose to update to a newer version of the library when they're ready to do so.

Hope this helps.
Received on 2018-01-02 18:28:40 CET