I've been using svn on and off for a while, and have recently started
using it at work after finally managing to migrate from SourceSafe.
We have what might appear to be a slightly peculiar code hierarchy, and
it's true that it was largely begat from using multiple SourceSafe
databases, overlaid on top of one another, but it's what we have and isn't
changing any time soon.
A simplistic cut-down view of what we have is:
# CORE is common code shared amongst projects, in one repo.
CORE-REPO/
Source/
Include/
CORE/
<CORE include files>
CORE/
<CORE sub-directories of code>
etc.../
# An individual project, using CORE, in its own repo
PROJ-REPO/
Source/
Include/
PROJ/
<PROJ include files>
PROJ/
<PROJ sub-directories of code>
etc.../
(yes, there's actually trunk+branches+tags at the real top, & a plethora
of other subdirs, but you get the gist hopefully).
Then the PROJ root has svn:externals set such that it pulls in the
(versioned) Include/CORE and Source/CORE bits that it wants, ending up with
a combined build area:
PROJ-BUILD/
Source/
Include/
CORE/
<CORE include files>
PROJ/
<PROJ include files>
CORE/
<CORE sub-directories of code>
PROJ/
<PROJ sub-directories of code>
etc.../
And it all works a treat (even, in fact, with a third layer in between,
in much the same way).
Now to the question. On occasion, someone working on PROJ is going to
want to commit fixes (required by PROJ and impl. & tested in a PROJ build
area) to CORE. Fine, this works too. But sometimes, we are going to have
(have had) fixes in Source/Include/CORE *and* Source/CORE which go together,
and, in an ideal world, would go in in an atomic commit.
And I was wondering what people thought was the best way of going about
it. So far, we've just taken the hit/risk of doing 2 commits (one from
Source/Include/CORE and one from Source/CORE).
I considered pulling CORE out elsewhere, exporting the 2 CORE bits to
that location, and committing from there, but that's a bit of a faff.
I've also just thought of creating as temp. branch in CORE, switching
both the PROJ copies to it, committing twice to the branch, and then
atomically merging that back to trunk. But that's a similar faff.
Although I could probably script that process with a uniquely-generated
branch name (and, as I type, I'm thinking that'll be the way to go).
I did, of course, just “try it”. From PROJ-BUILD/Source:
svn ci Source/Include/CORE Source/CORE
.. but svn doesn't like that; it seems to “see” the PROJ svn binding in
the common directory, and then complains that the locations' repos. have
mismatching UUIDs (the one from PROJ and the one from CORE), eben though
both locations in question come from the same repo (CORE).
I even tried from *within* one of the dirs, Source/CORE:
svn ci . ../Include/CORE
.. but got the same UUID error. Which may technically be a svn bug.
So, any thoughts? (Excluding the ‘obvious’ re-organise all your build
trees!)
--
[n...@fnx ~]# rm -f .signature
[n...@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[n...@fnx ~]# exit
