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? 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? Once the Git migration is done (no commits in trunk allowed in SVN), can we safely continue to use http://svn.gna.org/viewcvs/etoile/web/ for our website? >>> 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. Cheers, Quentin. _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
