Hello Ben and John,
Excerpt from Ben Fritz: -- <snip> -- >> 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. I also had something like the above in mind. But i had not realized that this also would have consequences for Brams repo. Good Point! > 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. If i had to do it i probably would use this workflow. It gives a lot control about what is being changed. But you right we will need to ask Bram. > 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 > -- Regards, Thilo 4096R/0xC70B1A8F 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F -- 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
