On Mon, Apr 28, 2014, Jon wrote: > On Mon, Apr 28, 2014 at 10:03 AM, LRN <[email protected]> wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 28.04.2014 17:04, JonY wrote: > > > 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). > > > > My experience so far: > > 1) When i build gcc, i often need to build mingw-w64-headers, mingw-w64-crt > > and winpthreads not together, but separately, at different points of time. > > To > > this end i'm svn-checkouting from a subdirectory to get only one of the > > three. > > I don't remember whether git has that ability; possibly not. If that is the > > case, these may need to go into separate repos (possibly submodules?). > > > > 2) The git branches are for "branching out" from the main development line > > (and merging back at some later point), not for completely separate stuff. > > If > > you keep completely different stuff in different branches, switching > > branches > > (which usually takes less than a second) will take a long time (depending > > on > > the size, up to 10 seconds or more). The svn "branches" are more like git > > "repos" - completely independent, they just "live together" :) > > > > > While you're investigating different git repo structures, I highly suggest > you investigate git's lightly documented "orphan" branches. These allow > multiple disparate branches to exist in a single repo. They allow you to > create "blank slate" style branches based upon a very early initial commit. > They work quite different than the merge friendly git branches you > typically see documented. You can still cherrypick from other branches if > needed. > > https://www.kernel.org/pub/software/scm/git/docs/git-checkout.html > > For example, say you want winpthreads on it's own branch that doesn't > contain winpthreads unrelated commits. Create the orphan branch similar to > > # <start_point> is an initial commit that typically includes only your > `.gitattributes` and `.gitignore` files. Consider > # <start_point> to be the "primordial" branch commit. > git checkout --orphan winpthreads <start_point> > > # discover that the primordial branch commit <start_point> is already > staged; commit it > # as the winpthreads branch initial commit > git commit -m "Initial commit; project attributes and ignores" > > # add all the winpthreads specific code to this otherwise > git commit -am "Add winpthreads source" > > # tag the commit with a well-known tag (IIRC, these types of tags are > isolated to a single branch so you > # likely want some namespacing) > git tag winpthreads-0.5.1 > > # what have I just done? > git log --decorate --oneline > > # make it so > git push && git push --tags
Aren't they a bit difficult to manipulate and error-prone (accidental merges or data exchange between branches)? At least that's my feeling. > Regarding git vs. mercurial on windows, I use both on a daily basis, like > both, but prefer git. The only performance complaint I've had relates to > garbage collection. If you try to `git gc --aggressive --prune=now` a large > repo, you'll often find that the gc fails due to memory issues even on my > 23GB x64 laptop. This is easily solved by setting the `gc.aggressivewindow` > config option to a lower value. I'm interested in hearing what perf issues > John E. has run into. When looking at the size of the git-svn clone I have a few minutes ago, I tried git gc --aggressive and it took a bit over 2GB of memory. As you said, it's a matter of setting the right values (and I believe the default ones in git are not sane) but the first thing is that --aggressive is usually not needed nor very useful. It is nice to save as much space as possible but during my test it saved only around 5% (from 67MB to 64MB) and is not something that runs automatically. I don't think the memory usage for this operation is an issue in practice since few people run it. (also I think git spreads the work on several threads, possibly inflating the memory usage by as much) -- Adrien Nader ------------------------------------------------------------------------------ "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
