subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Bird <n...@fnxweb.com>
Subject Committing different dirs to one external repo
Date Thu, 15 Jul 2010 12:37:48 GMT

   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!)

-- 
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit


Mime
View raw message