Hey Quentin, On Feb 24, 2014, at 6:02 PM, Quentin Mathé <qma...@gmail.com> wrote:
> Hey Eric, > > Le 22 févr. 2014 à 01:44, Eric Wasylishen a écrit : > >> Hi David, >> >> On Feb 21, 2014, at 2:39 AM, David Chisnall <thera...@sucs.org> wrote: >> >>> On 21 Feb 2014, at 09:28, Eric Wasylishen <ewasylis...@gmail.com> wrote: >>> >>>> Hi again, >>>> >>>> I just removed ParserKit, SourceCodeKit, and ObjC2JS from the >>>> https://github.com/etoile/Languages repository. They’re now standalone git >>>> repositories: >>>> >>>> https://github.com/etoile/SourceCodeKit >>>> https://github.com/etoile/ParserKit >>>> https://github.com/etoile/ObjC2JS >>> >>> That's great! Thanks for all of the effort that you've put into this! Do >>> you have a rough estimate as to when we should have the >>> no-more-commits-to-gna-please flag day? >> >> No problem! >> >> I set up a repository https://github.com/etoile/EtoileFetch that contains a >> directory skeleton containing only GNUmakefiles (Etoile/etoile.make >> Etoile/GNUmakefile, Etoile/Frameworks/GNUmakefile, etc.), as well as a bash >> script that clones all of the git repositories. >> >> Quentin and I are planning to release CoreObject at the end of the month so >> we’ll be busy with that,… but sometime in the next 2 weeks might work for >> the “stop committing to gna” date. I haven’t talked to Quentin about the >> migration in a while; I expect he’ll want to have the build scripts in >> /Etoile/BuildScripts working with the git repositories first, and see if the >> EtoileFetch plan I sketched out looks sensible. > > EtoileFetch looks good :) I'll try it in the next days, and see if any > adjustements are needed in the current build process, and for the > BuildScripts. > > I would just change the organization a bit… Put etoile-fetch.sh inside the > Etoile directory, turn the latter directory into the root directory, and > probably rename EtoileFetch to Etoile or EtoileTrunk if it's possible. Am I > overlooking some aspects that explains the current organization? no, those suggestions sound fine. I just renamed it to: https://github.com/etoile/Etoile and made the Etoile subdirectory the root. > Another thing we should probably do is to add the BuildScripts and > Dependencies directory to the the current Etoile directory. For Dependencies, > we would just have an empty directory (exactly as Frameworks for instance). > For Dependencies/libdispatch, we can probably have a distinct repository for > this libdispatch fork, and it can be checked out by etoile-fetch.sh along > other modules. > > For the BuildScripts, would it better to put them into another repository? > Agree, libdispatch should go in its own git repo and be cloned into a Dependencies directory by etoile-fetch. The BuildScripts could either go into Etoile or a separate BuildScripts repo. A separate BuildScripts repo would fit the design of the scripts better since they currently check out Etoile SVN trunk as part of the scripts. > Once the Git migration is done (no commits in trunk allowed in SVN), can we > safely continue to usehttp://svn.gna.org/viewcvs/etoile/web/ for our website? I don’t see any problems with that. > >>>> At this point the only things left on my TODO list for the git migration >>>> are: >>>> - make a simple script that git clones/pulls all of the Étoilé repositories >>>> - make a copy of the existing BuildScripts that uses the above script, and >>>> can successfully build everything >>>> >>>> >>>> I looked at various tool options (git submodules, git subtrees, etc.) for >>>> managing git repositories with dependencies on other repositories. Here >>>> are a couple of blog entries that were interesting: >>>> http://makingsoftware.wordpress.com/2013/02/16/using-git-subtrees-for-repository-separation/ >>>> http://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/ >>>> >>>> At the moment, none of these tools look a good fit for our use case. I >>>> think we should just use use “vanilla” git, plus the script I’ll write, >>>> which will satisfy people who want to check out every single module / >>>> automatic builds that need everything. >>> >>> I think we have two cases. I'd like to allow trunk for each repository to >>> develop more or less in isolation, but it would be nice to have a releases >>> repository that would contain references to specific commits in other >>> repositories so that we users could just git clone the etoile-release repo >>> and get everything, but people actively involved in development should run >>> the script to get trunk of everything. >>> >>> David >> >> Yes, that sounds like a good idea. > > I agree.
_______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
