[ocaml-infra] New Git repository in ocaml GitHub org

[David Allsopp]

See https://github.com/ocaml/ocaml/pull/1014#issuecomment-273739477 - also note that tools/processChanges.ml allows the database to be used to generate Markdown or HTML with fairly minimal new coding. The script for *generating* Changes is clearly on the critical path and will update with any future changes in ideas; the script for converting Changes back to fragments is not - it seems sensible to keep the original files, therefore.


David

> -----Original Message-----
> From: Infrastructure [mailto:infrastructure-bounces at lists.ocaml.org] On
> Behalf Of Yotam Barnoy
> Sent: 25 January 2017 14:49
> To: Gabriel Scherer <gabriel.scherer at gmail.com>
> Cc: infrastructure <infrastructure at lists.ocaml.org>
> Subject: Re: [ocaml-infra] New Git repository in ocaml GitHub org
> 
> Why not just delete the separate files with each release?
> 
> > On Jan 25, 2017, at 9:39 AM, Gabriel Scherer <gabriel.scherer at gmail.com>
> wrote:
> >
> > The git sub-module is an optimization. The change that is being
> > discussed is to each changelog entry in a separate file, to reduce
> > Changes-related merge conflicts. David wrote a script to rebuild a
> > complete Changelog from an exploded representation (sections are
> > directories, entries are files).
> >
> > Several developers have argued that keeping too many small files in
> > the repository could make it inconvenient to work with on some
> > OS/filesystem combinations (mostly Windows, I suppose). There can be
> > several hundred entries per release, so it is not an unreasonable
> > concern I think.
> > David's idea is to only keep the small files in the main repository
> > for the in-development versions, and at release time move them to a
> > separate repository, so that they are not pulled in by default.
> > Ideally we want each commit in the main repository to point to a
> > specific commit in the Changes-repository (the commit of the last
> > release-time move), so using a submodule makes more sense than a
> > separate branch -- with a separate branch there would be no link
> > between the versions in the two branches.
> >
> > I agree that in general submodules can be a pain to use, but in this
> > specific case I think that this is not likely to be an issue: most
> > people would never need to pull the submodule or update it in any way,
> > it would only need to be manipulated at release time (pull, copy
> > files, commit, and that's it), which occurs infrequently.
> >
> >> On Wed, Jan 25, 2017 at 3:30 PM, Anil Madhavapeddy <anil at recoil.org>
> wrote:
> >>> On 25 Jan 2017, at 14:22, Daniel Bünzli <daniel.buenzli at erratique.ch>
> wrote:
> >>>
> >>>> On Wednesday, 25 January 2017 at 14:45, David Allsopp wrote:
> >>>> It is desirable to keep the fragment files, but these add
> >>>> considerable weight to the main repository (and OCaml sources
> >>>> tarball). I have proposed in the solution using a Git submodule to
> store the archived entries.
> >>>
> >>> Are you sure about this ? It seems to me that git should be able to
> handle this without too much problem and it should be easy enough not to
> include them in the release tarball. I personally had a terrible
> experience with git submodules (though that was a long time ago) and I
> wouldn't advise anyone to get into this mess.
> >>
> >> Git submodules are indeed surprisingly difficult to use reliably.
> >> Would storing the fragments in an independent branch be workable?
> >> Those objects would not add more weight to a checkout of OCaml trunk,
> >> but still be accessible a checkout away.
> >>
> >> (Caveat: I haven't reviewed the rest of your proposal in detail,
> >> David, so apologies if this is well-trodden ground).
> >>
> >> Anil
> >> _______________________________________________
> >> Infrastructure mailing list
> >> Infrastructure at lists.ocaml.org
> >> http://lists.ocaml.org/listinfo/infrastructure
> > _______________________________________________
> > Infrastructure mailing list
> > Infrastructure at lists.ocaml.org
> > http://lists.ocaml.org/listinfo/infrastructure
> _______________________________________________
> Infrastructure mailing list
> Infrastructure at lists.ocaml.org
> http://lists.ocaml.org/listinfo/infrastructure