I searched a lot about this kind of problems.
Of course the solution is svk but I found svk not very reliable. I had some
problems with it, specially when mirroring a repo sometimes it stops because
special characters in the filenames or who knows.
I did some mixtures between both too.
You can use svk, mirror the main repo, create a copy of that mirror and work
with that copy through svn. Once the development finishes merge this copy
back to the mirrored svn with svk and it will be automatically merged to the
main repo.
I tryed to make SVNMirror work but I couldn't. It was difficult to find and
install and I don't know if it works at all.
Another manual solution I did sometimes is:
When you want to merge, checkout from the main repo,
export on the same folder from the local repo, overiding all the files (you
have to do this manually using svn export --force, tortoise does not have
the force option).
This way you have a working copy of the main repo but the files of the local
repo.
Commit and resolve conflicts if any
Fabio
----- Original Message -----
From: "Sergio Graça" <sergio@inplus.com.br>
To: "Shem Page" <shem.page@redvespa.com>; "Ryan Schmidt"
<subversion-2007a@ryandesign.com>
Cc: <users@subversion.tigris.org>
Sent: Thursday, January 25, 2007 08:26
Subject: RE: Slave repository
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 15 21:48:26 2007