subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Hartman <hartman.nat...@gmail.com>
Subject Re: How to combine files from different svn locations into a working copy?�
Date Sun, 10 Dec 2017 03:54:33 GMT
On Dec 9, 2017, at 12:02 PM, Bo Berglund <bo.berglund@gmail.com> wrote:
> 
> I have finally made a test conversion of our CVS(nt) repositories
> (note1) and now I need to grasp how to work with our code via svn.
> Specifically on the PC programming side we are using a number of
> common source files in many different projects.

FWIW in our firm we use svn externals for this. All our projects are in a monorepo (single
monolithic svn repository). Each project has its own trunk/branches/tags directories. The
shared code is organized as "libraries" which does not necessarily mean DLLs, but which does
mean that they are treated like any other project, with their own trunk/branches/tags, their
own version number (not related to the revision number of the repository), development rules/policies,
and release cycle. When a larger encompassing project uses such a "library," somewhere under
that larger project's trunk directory is a subdirectory with the svn:externals property set
to fetch the code of the dependency. Usually we fetch only the "src" subdirectory of the library,
because tests, documentation, etc., are not needed. The following is important: in the text
of this property, we use the caret (^) syntax rather than specifying an absolute URL so that
if the repository is ever moved to a different server, the links will not be broken (i.e.,
checking out old revisions will work correctly) -- this works because of our monorepo; furthermore
we use (IIRC) the @ syntax to specify the exact revision of the external code that we want
to use. This is so that the library can continue evolving on its own schedule without causing
breakage in dependent projects, which evolve on their own different schedule. When a project
decides to update to a newer version of the library, it can do so by changing the external
property to refer to the newer revision.

Since you asked about sparse checkouts... Note that because all our projects, including such
"libraries," are in a monorepo, we can take advantage of Subversion's atomic commits to do
global cross-project refactoring such as renaming an identifier in a library and updating
all code that will be affected throughout all dependent projects in one atomic commit transaction.
This usually requires a checkout that encompasses all such code, which in our case would be
huge. One consequence of each project having its own trunk/branches/tags is that a full repo
checkout will not only fetch all projects, it will fetch every tagged revision and every branch
of every project. This is where sparse checkouts (the "telescoping" feature -- see the --depth
argument) come in handy. Currently there is no viewspec to automatically checkout a specific
layout (I think someone is working on adding that; not sure though) so we have some Windows
.bat files and Unix shell scripts that put together these kinds of checkouts -- generally
this means getting each project (the parent directory of the trunk/branches/tags) with --depth=immediates,
then updating its trunk directory to --depth=infinity. (I am writing this from memory so please
excuse if the argument names are wrong.)

Hope this is helpful. The svn book explains these features quite well.
Mime
View raw message