On Mon, Apr 28, 2014, LRN 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?).
This is definitely not doable and is at odds with the way git works.
Checking the sizes in the 3.1.0 release I get:
% du -hs mingw-w64-*
21M mingw-w64-crt
48K mingw-w64-doc
45M mingw-w64-headers
4.4M mingw-w64-libraries
4.1M mingw-w64-tools
Separating tools, libraries (which includes winpthreads), doc would not
be useful to save download time.
Anothe experiment: size taken by git itself (remember there is from a
tarball and there is no history):
git add . && git commit -m 'Initial commit' && du -hs .git:
27M .git
same for each mingw-w64-* directory:
13M mingw-w64-crt/.git
120K mingw-w64-doc/.git
13M mingw-w64-headers/.git
2.3M mingw-w64-libraries/.git
1.4M mingw-w64-tools/.git
A single repository would save 10% download size or so.
I also have a git clone of the current SVN repository. The size of the
.git directory is under 70MB and that's with full history; shallow
clones would use even less, possibly not much more than the download for
only the headers.
Note also that, SVN fetches are slow while git's are much faster. IIRC
SVN does one request per file in a sequential manner or something like
that. Git will download the data packed in a few files and will be able
to max out your connection (or the server's).
I'd say you can expect fetches to be 10 times faster with git than with
svn for the same amount of data.
If you do these operations really frequently, you should probably setup
local clones of the git repository: serving them locally is absolutely
trivial (i.e. nothing to do) and updates should be near-instantaneous.
--
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
