Re: Weird behaviour when importing from a subversion repository (empty dir/ambiguous argument)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



HH-developing@xxxxxxxxxxxxxxx venit, vidit, dixit 10.04.2011 12:28:
> Hi everybody!
> Iâm a software developer in lower Austria and started introducing subversion in my company some time ago. It was mainly for myself to have a history. Now when I looked for myself I came to git. 
> When Iâm more comfortable with it weâll switch at company too.
> 
> So Iâve tried to clone our main project and I got an error. I have to say I cloned some other even bigger subversion projects and it worked, so something must be special here.
> I hope you read this long mail, I tried to separate it in sections and tried to shorten the output a little bit.
> 
> 
> My command:
> git svn clone "[subversionrepo]"  [gitclonedir] -T trunk -b branches -t tags --username [subversionuser]
> 

"git svn --version" please :)

> 
> The error:
> fatal: ambiguous argument 'a41f9bd5959dde85035bd047bf730cc62eaee12a^..1cb281cf44644da76ed94764f7770bb9e11d7424': unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions
> rev-list a41f9bd5959dde85035bd047bf730cc62eaee12a^..1cb281cf44644da76ed94764f7770bb9e11d7424: command returned error: 128
> if I do the same with --no-follow-parent, it works, but I assume then Iâm losing the branch/tag connection to the trunk. If Iâm losing the branches I can live with it (I think I did more branching in the last days with git, then with subversion the last year â ), but Iâm interested and if there is a possibility Iâll prefer to import the subversion project completely.
> 
> 
> 
> I did some further investigation:
> âgit log a41f9bd5959dde85035bd047bf730cc62eaee12aâ works giving me:
>     git-svn-id: [subversionrepo]/branches/Pluginstruktur-HEH@158 ebb3a944-7b90-0446-bc25-369ed2d31b3f
> git log a41f9bd5959dde85035bd047bf730cc62eaee12a^ (this should be the parent, right?) says âunknown revision or path not in the working tree.â
> 
> 
> 
> I think itâs a failure I did in subversion some months ago:
> Rev 158: Created an empty folder 'Pluginstruktur-HEH'.
> Rev 159: Deleted folder â Pluginstruktur-HEHâ (donât ask why)
> Rev 160: branched from trunk to branches/Pluginstruktur-HEH
> 
> So in Rev 158 there was an empty folder in branches, in Rev 159 no folder and in Rev160 a non empty folder out oft he trunk.
> Perhaps this ist the problem, because between Rev 158 and Rev159 there was a single empty folder an das I found out git doesnât track empty folders. Perhaps thatâs why Rev158 (git: a41f9bd5959dde85035bd047bf730cc62eaee12a) doesnât have a parent here.

The problem is that r158 has no parent - you started with an empty
folder and created a new root commit (just like git checkout --orphan)
which happens to be empty.

In several places, "git svn" assumes that "A^ B" makes sense, particular
that A has a parent. We fixed a couple of these in the past, which is
why I asked for your version above.

> Maybe you can shed some led in this and how I may solve this.  Can I just leave out revision 158 and 159 when doing git svn clone, because it was nothing more than creating an empty folder and deleting an empty folder? Iâve read somewhere on the net you can also use a svndump as base for a git import, perhaps I then may leave rev 158/159 out in the dumb, but I donât know how to use exactly an svndump as a git import and also if this wuld be a solution for me.

You could first clone up to and including r157, and then fetch from r160
in your case. Still, "git svn" should be able to cope.

Michael

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]