thanks for your answer!

It's very impressive if you are able to check out any revision on Trunk 
> and get the externals *at the correct revision on their Trunks*. Then 
> you must have some serious automation (or detailed manual process) in 
> place :)

We are using fixed revisions on externals, to ensure the integrity of each 
revision. Of course during early development their are times, that no fixed 
revsion is set, so the migration should be able to handle this by taking 
the date to determine the most likely external. 

Personally I find svn:externals to be an often misused feature; they 
> require a self control I rarely find (or exhibit myself) to be used 
> well. I tend to remove them wherever I find them.

i agree with you, and personally i want to go away from 
externals/submodules to something other like CMake external project or 
similar, but i can't change the past, so until now i/we have to live with 
that :)  

Your possibility of finding a solution depends a great deal on your SVN 
> repos and the use of externals. E.g. if your various projects all have 
> their own TTB-roots and all svn:externals only refer to locations in 
> other projects (i.e. svn:externals on tags refer to tags in other 
> projects), then I don't really see any theoretical problem with 
> conversion. However, svn:external can be used in much more "creative" 
> ways than that...

until now i think we used it in a normal way - but i don't know what i will 
find during the migration...

>  Have you looked at https://github.com/hbt/git-svn-migration

i will take a look! thank you!



You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to