I had the same problem in my project and the only solution I have found was SVK.
I am working on a Project that we have two different subversion repositories, on different servers, one that is keeped by one team that maintain a production repository and other that a group of developers work on.
In our project, the production team creates a branch and "synchronize" it to developers repository, after work is done we return the branch back to the production repository, merging the code back.
We are using SVK to do that and it is working fine until now. We are still testing it.
Hope this helps.
Sergio
Thu, 25 Jan 2007 09:00:49 +1300, "Shem Page" <Shem.Page@redvespa.com> escreveu:
> > -----Original Message-----
> > From: Ryan Schmidt [mailto:subversion-2007a@ryandesign.com]
> > Sent: Wednesday, 24 January 2007 6:17 p.m.
> > To: Shem Page
> > Cc: users@subversion.tigris.org
> > Subject: Re: Slave repository
> >
> >
> > On Jan 23, 2007, at 19:06, Shem Page wrote:
> >
> > > We are using subversion + the gui supplied by tortoise but
> > my question
> > > is really about the big picture of source control not so much
> > > implementation of a particular product. Any advice will be helpful.
> > >
> > > We have gone into partnership with another company in a different
> > > country, and will be making changes to code which about 3
> > groups can
> > > alter. The original repository is based elsewhere and due to
> > > connection speeds, time differences and working relationships it is
> > > not practical for us to work directly from it. So what we
> > wanted to do
> > > was to check out a slave copy (dated, tagged, whatever, at a stable
> > > point in time), and then with that slave copy make it OUR
> > repository
> > > stored on a server which then in turn each one of our developers
> > > checkout and in from. We need to be able to check our changes back
> > > into the original source when we are ready but will be
> > working off our
> > > own repository.
> > >
> > > Visual?
> > > =====
> > >
> > > Foreign Server | Our
> > > Server | Our Developers
> > > =============|============================|==================
> > > Source 1.0 | Source 1.0
> > > snapshot | Source 1.0 checkout
> > >
> > |
> > > <--regular check ins + updates --> |
> > > |<-- infrequent check ins and updates -> |
> > >
> > >
> > > What I don't know about is this idea of checking out source and
> > > then making that checkout a repository for others to check out. I
> > > know we can export and import a project into a repository, but if
> > > we don't keep that source control link between the two servers we
> > > will slide out of date from their other developer groups. This is
> > > an untested working relationship which is why we want source
> > > control where ever possible, but we also some independence from
> > > other groups who may check in broken code.
> > >
> > > Does this make sense? Is it something which is quite normal or are
> > > we misunderstanding the way source control works?
> >
> >
> > Subversion does not let you use master/slave repositories in this
> > fashion. However, look into SVK, which is based on Subversion, and
> > does offer that.
> >
> > http://svk.bestpractical.com/
> >
> >
>
> Yes I had found some posts on the net which referred to SVK, which is
> how I started thinking about a master slave solution, unfortunately I
> wasn't aware subversion doesn't support such concept. Even less
> fortunate is the fact that we must use subversion, as that is what is
> already in place in our partners environment.
> Is there another way around this problem. Can we simply import our work
> into a branch on their repository and force a merge? The problem about
> that idea is I don't think subversion would be able to manage the merge
> because it would be seen as two different projects.
> Ideas?
>
> Thanks
> Shem
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 25 12:27:06 2007