Timeline for Mercurial Repository structure with heavyweight corporate comms, configuration management & test requirements
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 12, 2017 at 7:31 | history | edited | CommunityBot |
replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
|
|
| Jan 11, 2012 at 15:52 | vote | accept | William Payne | ||
| Jan 6, 2012 at 14:35 | comment | added | William Payne | Once I have got something working, I will describe the system that I have implemented, and how it works (initially, at least). Thanks again to everybody for their contributions. | |
| Jan 6, 2012 at 14:27 | comment | added | Mark Booth | When I get the time I will summarise our chat in my answer and we can tidy up these comments. | |
| Jan 6, 2012 at 13:53 | comment | added | William Payne | let us continue this discussion in chat | |
| Jan 6, 2012 at 12:09 | comment | added | Mark Booth | @WilliamPayne - It's much easier to combine repositories than to split them. Please do more research on this before you take this path, my feeling is that you will regret it enormously down the line. We are currently moving from a monolithic (svn) repository to modular (git) repositories and it is a real pain. We are doing it piecemeal to mitigate the risk of a single big switch & it is going to take a long time to move to the new modular structure. It is so difficult that we have basically decided to start new repos from scratch, leaving the history only in the old svn repo, for reference. | |
| Jan 5, 2012 at 19:33 | comment | added | William Payne | Since we are just starting out, I think that it makes sense (for us) to start with a monolithic repository at first, then split things up later if/when configuration management concerns dictate that we do so. I want to get our development automation (CI etc...) up and running sooner rather than later, so anything that I can do (at this stage) to simplify things will help. | |
| Jan 5, 2012 at 18:35 | comment | added | Mark Booth | @WilliamPayne - Monolithic vs Modular repositories are a whole other question, I quite like the second half of this answer (Nested Repositories and the Forest Extension have been superseded by Sub-Repositories, but the rest is still current). | |
| Jan 5, 2012 at 15:03 | comment | added | William Payne | Thank you. I will look into sub-repositories as a way of imposing a structure. By the way, what are the arguments against having a monolithic repository, apart from pragmatic size/performance arguments (which I do not buy into, 'cos I want everybody to have the latest of everything on their workstations, anyway). | |
| Jan 5, 2012 at 14:57 | comment | added | William Payne | RE: Other issues. I am happy to keep test data out of version control, as long as the directory structure in which it is stored is well defined, and enforced via some mechanism. The bigger issue was the storage of test results & intermediate data, again , kept outside of version control, but stored in a directory structure where the path indicates which repo, branch & revision the code that generated it came from. I achieved this in the past by generating a 4 digit hash from the SVN branch path. 1=trunk; 2-999=tags; 1000-9999=branches. I can do the same in Hg using the repo name, probably. | |
| Jan 5, 2012 at 14:54 | comment | added | Mark Booth |
@WilliamPayne - Thanks. While Mercurial is flexible, with appropriate repositories, branches and hooks you can build in whatever restrictions you want, at the organisational or repository level. Personally, I would start simply with organisational controls, and a few CI hooks, and extend those controls in the future as their need becomes apparent. Also, judicious use of sub-repos could, for example, encourage people check things out locally in the same structure as it is on the server, for instance by having productLines or bigImportantCustomer as super-repos.
|
|
| Jan 5, 2012 at 14:51 | comment | added | William Payne | RE: Workflow. I think that the simplest workflow would be to pull from a "daily" repository, work on it locally, then (frequently) push back to the "daily" repository, kicking off static analysis, smoke tests & regression tests via the CI system. I am happy for the main repo to be "broken", as long as I know about it, and as long as it gets fixed again quickly. In fact, I am considering making committing to the "daily" repo the only way that one can compile & build, to encourage frequent commits & good test coverage. (Far more important than the ability to work in isolation, IMHO). | |
| Jan 5, 2012 at 14:48 | comment | added | William Payne | RE: Directory Organisation. I was using the source directory organisation as a subliminal means of communication; imposing an implicit structure on the organisation of the code (and through that on the business as a whole). I am beginning to understand that Mercurial tends to be used in a very very flexible way; but I really want to constrain some of that flexibility to impose a structure on the way that people think about the business by imposing a structure on the way that their documents are organized on their workstations and our network storage areas. (More corporate comms than tech.) | |
| Jan 5, 2012 at 14:41 | comment | added | William Payne | RE: Branch Organisation. I agree that the first organizational chart can happily be ignored. It did not communicate the workflow particularly well, anyway, and so was not providing any real utility beyond reinforcing convention. I would like to replace it, however, with something that strongly communicates a (simple-as-possible) workflow, and encourages frequent commits. Perhaps calling the main "trunk/development" branch "daily" would do that? | |
| Jan 5, 2012 at 14:37 | comment | added | William Payne | Again, another excellent and informative answer. Thank you. | |
| Jan 5, 2012 at 11:55 | history | answered | Mark Booth | CC BY-SA 3.0 |