Re: sync repositories

[jlcarpenter]

I have been working on a pair of Ant tasks that support merging code from N
number of sub-development groups with their own source trees into the main
branch of a cvs repository.  How the remote sources are being stored is
irrelevant to my custom Ant tasks. (In my case the other team is using the
ENVY repository built into VAJ.)  From an overall standpoint it is
important that the entire ant build script has some way of obtaining the
external source tree from each external sub-development group and updating
each external sub-development group's SCM repository.

I am more than happy to share the workload of developing the ant tasks with
another developer outside my company.  In fact I would like to submit the
new tasks to the Jakarta project when they are complete.  The vast majority
of the work is already done but there is still several days of work to be
done before the tasks are complete.  Unfortunately I only have time to work
on the tasks during short stints between iterations of the main project my
group is working on.  Be warned that writting custom ant tasks as well as
understanding the tricky details of the problem that pop up is not for the
faint of heart.  Its not rocket science, but it is a bit tricky.  I expect
anyone new to the problem will take a day or more just to become aclimated
to everything that is going on.

Rather than regurgitate all the nasty details I ask that you browse the
archives of the cvs (and cvsnt) user and ant development lists for my
postings.  They are all made under this email
address:(address@hidden;address@hidden) or
address@hidden

If there is a better way to do all of this without writing custom ant tasks
please let me know!

James Lee Carpenter
Software Engineer
Household Technical Services
6602 Convoy Court
San Diego, CA 92111

ph: 858-609-2461
email: address@hidden


                                                                                
                                                        
                                                                                
                                                        
                           Eric Siegerman              To:     
"'address@hidden'" <address@hidden>                                  
                           <address@hidden>        cc:                          
                                                    
                           Sent by:                    Subject:       Re: sync 
repositories                                             
                           address@hidden                                       
                                                 
                           g                                                    
                                                        
                                                                                
                                                        
                                                                                
                                                        
                           10/10/2002 12:57 PM                                  
                                                        
                                                                                
                                                        
                                                                                
                                                        



On Fri, Aug 09, 2002 at 10:48:04AM -0700, Mike Ayers wrote:
> >>I have to sync two CVS repositories located on two non-
> >>connected networks.  (yep, this means tape/CDROM transports,
> >>I know it sounds silly).

This was discussed a couple of months ago, and a few approaches
were offered.

Now we have to do the same thing.  Not full synchronization,
actually -- every revision, log message, and tag replicated.  All
we really need is that two sites be able to work on the same
modules without stepping on each others' feet, and without being
able to share a CVS repo.

(We have to do it this way for political reasons, so digression
into why we "shouldn't" have to, or technical suggestions on how
to reduce it to a single repo, would NOT be helpful, i.e. I
already know about ssh.  I'm going to suggest BitKeeper, but I
very much doubt they'll go for it.  In short, I'm probably stuck
with disconnected CVS, whether I like it or not.  Bleah.)

So I'm wondering whether anyone managed to turn that old thread
into a concrete solution.



If not, I'd appreciate comments on the approach I suggested back
then -- actually a modification to something Paul Sander had
described.  Paul pointed out that my suggestion didn't meet the
original poster's needs.  True enough, and presumably because of
that, no further discussion of it took place ... but it does
appear to meet our, less stringent, needs; so a critique of it
from that perspective would be helpful.

Here's the original proposal:

On Mon, 19 Aug 2002 11:47:15 -0700, I wrote:
> On Fri, Aug 09, 2002 at 12:50:06PM -0700, Paul Sander wrote:
> > Each site owns its own trunk.  Each site creates a branch that is used
for
> > importing from the other site(s); these branches map to the trunk(s) at
the
> > remote site(s).  No local commits are permitted on the import branches.
> > Each site keeps a list of branches to export to the other site(s), and
> > tracks the latest exported versions on each export branch.
> >
> > To send an update from a remote site, the latest exported versions
table and
> > the export branch table are consulted, and all versions that have never
> > before been exported are packaged up and sent (and the tables are
updated
> > as needed).  Tags are also sent out in an appropriate manner.
> >
> > To receive an update, the received versions are checked into the import
> > branch(es) as needed, and the tags are translated accordingly.
>
> I just had an eeevil thought.  You're gonna cringe, I know, but
> bear with me :-)
>
> On system A, use a version of CVS which stores its metadata in
> subdirectories called "CVS_A"; on System B, store the metadata in
> "CVS_B".
>
> Now, on System A, CVS won't recognize System B's metadata; it'll
> revision-control CVS_B/Entries etc. like any other files.  And
> vice versa.  Thus, one should just be able to keep ping-ponging a
> single sandbox back and forth between the two systems (via email,
> FTP, sneaker-net, whatever), and each system will use its own
> metadata to stash the new revisions in the right place.
>
> The systems in question had better have the same line-ending
> conventions, of course...
>
> Does anyone know whether CVS can still withstand having CVSADM
> and friends defined to different values, or has "CVS" gotten
> hard-coded anywhere?  (I know of one place; the ign_default
> string in src/ignore.c.  That'd have to have "CVS" removed, and
> CVSADM added dynamically to the default ignore list.)

And my answers to the criticisms Paul made at the time:
  - "I thought the idea here was to propogate version histories
    between multiple repositories, not to keep multiple sandboxes
    in synch.  The method you propose does the latter..."

    As mentioned above, true, but in our case that's enough.  I
    think.  Are there reasons it isn't, that I'm not seeing?


  - "... and doesn't accomodate local changes to both sandboxes.
    It also provides no means to transfer other stuff such as RCS
    states and tags."

    Every resync involves getting a tarball from the remote site,
    importing it to the remote-site branch, and then merging from
    there to the trunk.  That should handle local changes to both
    sandboxes.

    It should also handle the only RCS state I care about, i.e.
    "dead" :-)

    As I mentioned, I don't care about replicating tags.


Thanks in advance.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
The acronym for "the powers that be" differs by only one letter
from that for "the pointy-haired boss".


_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs