On Monday, May 21, 2012 2:11:13 AM UTC-5, JohnBeckett wrote: > What directories should the group manage? > > A possibility is below, although it may be too ambitious. It > shows all first-level directories under runtime, with some to > be managed by a group, and the remainder run directly by Bram. > > The files in 'runtime' would NOT be part of the group repo, but > all files in each listed directory (and subdirectories) would be > part of the group repo. > > runtime (group) > +--autoload > +--colors > +--compiler > +--ftplugin > +--indent > +--keymap > +--lang > +--plugin > +--syntax > > runtime (Bram) > +--doc > +--icons > +--macros > +--print > +--spell > +--tools > +--tutor >
I thought about this too. I think we may need a new thread to discuss this at some point...but of course Bram gets the final say since he's the one pulling changes. What files go in the repository are in large part determined by how Bram wants to pull changes. At a high level, I see a few options: 1. Runtime repository is independent of the Vim repository. Bram pulls changes by updating to the latest of the runtime repository and manually copying files into the Vim repository. This would be most similar to the current method but doesn't provide much context to the runtime changes in terms of change history or how it ties to specific version of the C code. On the other hand, the history is "clean" as Bram is used to releasing. 2. Runtime repository is actually a clone of the full Vim repository. Bram uses pull/transplant/merge/whatever Mercurial command to just get the changes. Developers in the runtime repository just know not to modify the .c source files. Reviewers of the "outgoing" repository enforce this. I like this idea best. But the history will then show a steadily advancing main line and a potential tangle of branches and merges for the runtime files. I don't have a problem with that, but perhaps Bram wants a steady one-version-after-the-next "clean" history. 3. Runtime repository is a stand-alone repository with just the runtime files, but included as one or more subrepositories of the main Vim repository. This way the runtime maintainers would have full access to a repository and Bram would not need to worry about any unauthorized changes to the C code sneaking in. But it would require some somewhat disruptive changes to the current Vim repository. Also, if there are runtime files Bram *doesn't* want under team maintenance (like the stuff you list under "Bram" above), he'd either need to trust the team not to modify them as in option (2) above, or split the runtime into separate directories. On the bright side, to pull changes (or revert them if needed), Bram just needs to update one file to point to the correct version. I'm also not sure of the level of support for subrepositories on the various providers. There may be other ways of doing this I've not thought of. When deciding repository layout, unless Bram already has a strong opinion, it might be wise to ask for advice on Mercurial's "general" mailing list. See http://mercurial.selenic.com/wiki/MailingLists -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
