Hi,

It is indeed a large post and hard to read out the question(s) in there. In 
the middle part, you describe some complications with the live/pristine 
branches, but you also write that you have already solved this problem? I 
find the connection with the first and the last part a bit unclear.

You might get more replies if you try to isolate a smaller example, and ask 
simpler questions one at a time. 

I'm not quite sure how the external libraries are versioned in relation to 
your core project (with the trunk/branches/tag structure). Before I go on 
to think about how one could do lots of sub-tree merging and 
filter-branching to get these external libraries into your repository, I 
want to ask if you really want to do this.

Including the sources of 3rd party libraries is exactly what git-submodules 
are intended for, and even before I do this I would consider if it is 
possible to get away with rather some binary dependency declaration in the 
build-tool instead (this might not be fitting for your project, but it's 
worth considering).

Even if you do your own modifications of lua or the other libraries, it is 
still worth tracking them in their own repositories, and then load them in 
using submodules.

With this in consideration, what is the first thing you need to solve? You 
write that you haven't been able to convert with all the merges intact. Is 
this point crucial to complete the conversion?

On Saturday, October 6, 2012 7:33:42 PM UTC+2, Carsten wrote:
>
> Hi all, 
>
> in this blog post the author described a very nice (natural and simple) 
> way to deal with 
> "vendor branches" in Git: 
> http://happygiraffe.net/blog/2008/02/07/vendor-branches-in-git/ 
>
> This works very well (in fact, I use this approach for my website, too), 
> but observe how 
> the "upstream" ("vendor") branch file contents (the Wordpress files) is at 
> the same 
> directory level as the project itself. 
>
> With my main programming project, I'm in a very similar situation, and I'd 
> love to 
> extend this idea to manage the outside, external libraries (e.g. lua, 
> wxWidgets and 
> zlib) in a similar manner. 
>
> The key difference would be that the upstream branch had the libraries 
> *not* at the top 
> level: 
>
>      lua/ 
>      wxWidgets/ 
>      zlib/ 
>
> but have them all in a single shared directory: 
>
>      ExtLibs/ 
>          lua/ 
>          wxWidgets/ 
>          zlib/ 
>
> This would be important to have it match the main project (master) branch, 
> which had 
> both ExtLibs/ and additionally all the project-specific directories as 
> well. For example: 
>
>      abc/ 
>      bin/ 
>      ExtLibs/ 
>          lua/ 
>          wxWidgets/ 
>          zlib/ 
>      samples/ 
>      src/ 
>
> (Unfortunately, none of the Git books that I've read ("Pro Git" by Chacon, 
> "Version 
> control with Git" by Loeliger and McCullough, "Git" by Haenel and Plenz) 
> mention this 
> technique in their subprojects chapters. In fact, when you search, the 
> answer to "vendor 
> branches" seems almost always to be "submodules" or "subtrees". I see that 
> the above has 
> limits of its own, but seems to be a very good solution for most cases of 
> "vendor branch".) 
>
> In summary, all like in the blog post above, but with the extra 
> (sub-)directory "ExtLibs". 
>
>
> In this spirit, I had no problems converting my three websites from 
> Subversion to Git, 
> which were never structured in the Subversion standard layout, but right 
> from the start 
> like this: 
>
>      live/ 
>          cafu/ 
>          fsv/ 
>          rcgj/ 
>      pristine/ 
>          cafu/ 
>          fsv/ 
>          rcgj/ 
>
> This sequence of commands left me with a perfect conversion to Git: 
>
>      > git svn init svn://thubi-cfs/Websites --trunk live/fsv fsv 
>      > cd fsv 
>      > git config --add svn-remote.svn.fetch 
> "pristine/fsv:refs/remotes/pristine" 
>      > git config svn.authorsfile "d:/test/authors.txt" 
>      > git svn fetch 
>
> This also worked for website "rcgj", but with "cafu", in Subversion days I 
> had made the 
> "mistake" to merge e.g. from 
>
>    (a)   pristine/cafu/forum/   to   live/cafu/forum/ 
>
> (or some other subdirectory below cafu/), rather than at the top from 
>
>    (b)   pristine/cafu/ to live/cafu/ 
>
> In the above sequence, git-svn properly recognized the merges that were 
> made as in (b), 
> but not those made as in (a). 
>
> As a result, I had to tweak the newly converted "cafu" Git repository with 
> grafts, 
> baking them with "git filter-branch". 
>
>
> Back to my source code project, the Subversion repository is today 
> structured like this: 
>
>      cafu/ 
>          trunk/ 
>              abc/ 
>              bin/ 
>              ExtLibs/ 
>                  lua/ 
>                  wxWidgets/ 
>                  zlib/ 
>              samples/ 
>              src/ 
>          branches/ 
>          tags/ 
>      vendor/ 
>          lua/ 
>          wxWidgets/ 
>          zlib/ 
>
> That is, standard layout, plus one "vendor branch". 
>
> (Sorry that the name "cafu" appears here again, it's not related to the 
> website example 
> above!) 
>
> Unfortunately, the libraries are directly below "vendor/", there is no 
> "ExtLibs/" 
> between "vendor/" and the libraries. 
>
>
> The problem is that I cannot get this properly converted to Git. 
> (For brevity, I omit setting the authors file in the next examples.) 
>
> The straightforward attempt 
>
>      > git svn init svn://thubi-cfs/Project/cafu -s Project 
>      > cd Project 
>      > git svn fetch 
>
> works, but ignores vendor/ entirely. 
>
> Alternatively, 
>
>      > git svn init svn://thubi-cfs/Project/cafu -s Project 
>      > cd Project 
>      > git config --add svn-remote.svn.fetch "vendor:refs/remotes/vendor" 
>      > git svn fetch 
>
> works too, and also imports "vendor/", but similar to the "cafu" website 
> above, it 
> doesn't create any merges regarding "vendor". 
> As opposed to the website, the files in the vendor branch are also at the 
> wrong level 
> (ExtLibs is missing), so I cannot use grafts to manually postprocess the 
> import! 
>
> Third, I tried to re-arrange the repository layout in Subversion first, in 
> order to give 
> git-svn a better hint. That is, a Subversion test repository I made to 
> look like this: 
>
>      vendor/ 
>          ExtLibs/ 
>              lua/ 
>              wxWidgets/ 
>              zlib/ 
>
> using something like "svn move vendor/ temp/", "svn move temp/ 
> vendor/ExtLibs/ 
> --parents", then tried again as before. But unfortunately, this created 
> two more 
> revisions (and additional confusion), but didn't change anything else. 
>
>
> In summary, I've not been able to import the above Subversion directory 
> into Git with 
> all merges intact, or at least in a manner that I was able to fix in 
> postprocessing. 
>
> Btw., if you'd like to have a look at the real thing, the Subversion 
> repository URL is: 
> https://srv7.svn-repos.de/dev123/projects/cafu 
>
> and the authors file that I used was simply: 
> Carsten = Carsten Fuchs <carste...@cafu.de <javascript:>> 
>
>
> Thank you very much for reading this far! 
>
> I'm still a beginner with Git, and I'd be very grateful for any help or 
> advice about 
> converting this repository. 
>
> Best regards, 
> Carsten 
>
>
>
> -- 
>     Cafu - the open-source Game and Graphics Engine 
> for multiplayer, cross-platform, real-time 3D Action 
>            Learn more at http://www.cafu.de 
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/git-users/-/JKRolmtSIuoJ.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Reply via email to