Yeah, I tired this in a micro test with a couple of files and it looked
good. In the macro test with my massive bad imports it failed. The problem
is that the converter created two branches or a branch and a tag as a single
checking of 20,000 adds. That's a big commit to parse.
So, i'm going to have to create a skeleton from siginifcant tags instead.
History aggregated by build not by changeset is what we'll wind up with. I
don't love it, but it should be viable.
On Thu, Oct 23, 2008 at 1:32 PM, Konstantin Kolinko
<knst.kolinko_at_gmail.com>wrote:
> 2008/10/22 Peter Kahn <citizenkahn_at_gmail.com>:
> >
> > I recently used the Polarion converter to import my MKS repository to
> svn.
> > I had to make some changes to support a cutoff point based on date for
> the
> > export out of MKS. I confused the importer and now my svn repository has
> > branches the are really adds of 1000s of files instead of a proper
> branch.
> >
> > Is there a way for me to tell SVN that "project/branch/1.0_integration"
> came
> > from trunk @ revision 450?
> >
> I am sure that it is not possible.
>
> If a "branch" was created by add or import operations instead of svn copy,
> the only way that I know to workaround that is to use the
> '--ignore-ancestry' option.
>
> That is my knowledge since svn 1.4, and svn:mergeinfo should not
> make much difference here.
>
> > Right now, when I try to merge between branches merge the svn application
> > takes 100% cpu and gobbles up all of my ram before terminating with an
> > out-of-memory error.
> >
> It might be a different issue.
>
> (2Peter: resending. Sorry: forgot to CC the list at the first time.)
>
> Best regards,
> Konstantin Kolinko
>
--
Peter Kahn
citizenkahn_at_gmail.com
pkahnpie1_at_AIM
http://citizenkahn.myplaxo.com
Awareness - Intention - Action
Received on 2008-10-23 20:16:47 CEST