[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Can I convince svn 1.5 that a random directory is really a branch off of trunk?

From: Peter Kahn <citizenkahn_at_gmail.com>
Date: Thu, 23 Oct 2008 14:16:20 -0400

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

> 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
Awareness - Intention - Action
Received on 2008-10-23 20:16:47 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.