[svk-devel] SVK SVN Mirroring Scenario

[Justin Patrin]

On 7/9/07, Stine, Matt <Matt.Stine at stjude.org> wrote:
> Oh, I forgot to mention, we will continue to commit to our internal
> repository and nightly mirror the changes to Google Code.  So a dump and
> filter doesn't seem to be an option for us.
>

I don't see why this follows. You already said that you moved the
internal stuff to another repo. Why not filter out the internal stuff
from this repo that you want to mirror?

> - Matt
> matt.stine at stjude.org
>
> -----Original Message-----
> From: svk-devel-bounces at bestpractical.com
> [mailto:svk-devel-bounces at bestpractical.com] On Behalf Of Justin Patrin
> Sent: Monday, July 09, 2007 5:59 PM
> To: svk-devel at bestpractical.com
> Subject: Re: [svk-devel] SVK SVN Mirroring Scenario
>
> On 7/9/07, Stine, Matt <Matt.Stine at stjude.org> wrote:
> >
> >
> >
> >
> > We are getting ready to release a large body of code into open source,
> and
> > will be mirroring our local SVN repository to a repository located at
> Google
> > Code.  I have followed the online solutions available for doing this
> with
> > SVK, including the solution mentioned in the online SVK book.  I do
> have a
> > couple of tweaks that I need to do, and I want to find out the best
> way to
> > make this happen.
> >
> >
> >
> > We have used some proprietary modules that we cannot distribute, and
> up to
> > this point have maintained them in our repository. I have since moved
> them
> > to another repository.  Since I know that an SVN delete only removes
> from
> > the HEAD revision, I want to find a way to make sure that these are
> not
> > mirrored to the external repository.  In my understanding, an svk
> smerge
> > without the -incremental option will accomplish this, pushing only the
> HEAD
> > revision out. Is that correct? Also, is there a way to do this and
> maintain
> > the history for the other files?
> >
>
> I would suggest instead doing an dump of your SVN repo them filtering
> it to remove those things you wish not to be in the repo, then
> reimporting it. I would suggest doing the inverse to move the history
> of your proprietary modules to another repo.
>
>
>
> --
> Justin Patrin
> _______________________________________________
> svk-devel mailing list
> svk-devel at bestpractical.com
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel
>
>
>


-- 
Justin Patrin