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
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.
------------------------------------------------------------------------------
"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
