On 4/28/2014 19:53, Ruben Van Boxem wrote: > Different repositories may sound like a nice idea, but keeping them in sync > can be a pain, depending on the complexity of the subprojects. I believe > stuff like ironcrate, winpthreads and perhaps the mingw-w64-tools folder > deserve their own repo, as they are very seperate from the headers+crt. > These latter two I'd suggest to keep together, as that will reduce the > chances of wrong versions being used together and allow 1 commit to change > both to keep them aligned without any hassle. In contrast, I would try to > move away from a seperate "experimental" directory, and instead inject > these changes into a branch (or several, so that each finished feature can > be merged easily). Branches and merging are the git way, and rebasing > allows for clean merges. >
For ease of migration, every module in trunk would go into the same repo, so that would include winpthreads and mingw-w64-tools. I'm not sure if we can "exclude" files from the import unless we want to completely break apart trunk into components. However, I am also trying to avoid too many separate repos and git submodules. Right now, I am thinking of splitting it 3 ways, the mingw-w64 proper (with anything from experimental if applicable), web, and experimental (if it actually justifies a separate repo, otherwise, it might be archived and left as is on SVN). > The simplest setup would be to have these branches: > - master > |- 1.x > |- 2.x > |- 3.x > |- experimental_feature_x > |- experimental_feature_y > ... > And each release's git tag is in its release branch. Note a git tag is not > a full copy of a branch as with SVN, but just a ref to a certain commit. > One can easily and quickly diff branches and cherry-pick particular commits > between them, which will allow for simple git-based backporting of changes > as far as the different branches are similar) > A new release branch is as easy as > > git branch --track 4.x origin/master > Right, this is given. > Same for a new feature branch. This ensures changes in the master branch > are automatically pulled in when you do a "git pull". > > As a start for the conversion, check out this step-by-step plan: > http://stackoverflow.com/a/11918337/256138 > I have done a fairly large svn to git conversion recently, so I'm mostly familiar with the steps. > I haven't tested it myself, but this should provide the cleanest transition > possible, removing unnecessary svn stuff and transforming that as much as > possible into git structure. The good thing is you can try it locally > without touching the original repo. > > I could give it a whirl myself and push to github so you can see what the > result would be if you think this would be useful. > I want to avoid duplicate efforts, I have already started the git svn clone process. If it goes badly on my end, you can give it a go. I will push to an unofficial repo on SF for preview. Speaking of our current svn repo, it isn't usually busy, so the svn lock down will only be done once migration completes, users should be able to jump right over by then. Until it is done, the git repo will need to track svn manually.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
