Databases
StackOverflow2013
Postsdbo
POMonolithic vs multiple Mercurial repos for modules within a suite of related applications
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POMonolithic vs multiple Mercurial repos for modules within a suite of related applications
    primarykey
    data
    text
    <p>At my organization, we'd like to switch from using CVS to Mercurial for a variety of reasons. We've done a lot of investigation when trying to determine how we should organize our Hg repositories based on what we have in our codebase and how we tend to work. We've come up with satisfactory answers to most of our questions, but there's one point that's stumping us a little, and it's driving me mad because the most convenient way to organize the repo for our workflow just seems like the wrong way to go from a conceptual standpoint. I'm trying to figure out whether our perception of how this is "supposed" to work is wrong, or whether we're just bumping up against a legitimate feature gap in the available tooling.</p> <p>Primarily we maintain a medium sized codebase consisting of a suite of applications that get all get released in the same package. Conceptually you can divide our code into three categories:</p> <ol> <li>Shared code</li> <li>Application code for our primary suite (uses the shared code)</li> <li>Miscellaneous small utilities that are infrequently maintained (uses the shared code)</li> </ol> <p>This doesn't seem unusual to me, but I want to stress the point that we maintain the application code and the shared code at the same time and always want them to be bleeding edge with respect to each other. That is, we want all our application builds to always use the latest version and the same version of the shared code. We frequently add to or modify application code and shared code at the same time. Currently, the shared code is in one CVS module, and the applications are all in their own separate modules. The shared code and application modules are checked out such that the shared code gets built once and then linked into each application. We frequently do cvs commits that include changes across shared and application modules at once. We would really like to keep that ability.</p> <p>I understand that commits in Hg are atomic within repositories -- that's fine but I'd like to be able to diff and commit to an application and a shared library at the "same time" (i.e. I don't care if it's really atomic but I don't want to have to manually do two separate diffs and two separate commit actions).</p> <p>Conceptually, it seems like it would be correct to have one or a few repos for the shared code, and a separate repo for each application and each little utility program. This means you'd need to check out multiple repos for each build but that isn't a problem for us. The problem is there doesn't seem to be any tooling that lets you view updates or changes on multiple repos at once, or diff multiple repos at once and then sequentially commit them for you. This would be easy to script, but that wouldn't help developers who want to use various GUI frontends to complement the command line.</p> <p>It seems like in order to be able to commit across multiple codebases at once (from a user's perspective) and keep everything on the bleeding edge together, the only two solutions are:</p> <ol> <li>Use a monolithic repo with EVERYTHING in it.</li> <li>Create some subrepos but access/commit everything through a big monolithic "main" repo that contains all the subrepos to keep everything on the latest revisions (which doesn't seem any better than (1) to me).</li> </ol> <p>It can't be that unusual to want to work with multiple "peer" repositories at the same time, even if the actions aren't truly atomic across all of them -- and yet I'm not finding tons of articles or posts clamoring for this ability.</p> <p>In summary:</p> <ol> <li>We would like to organize our code such that we can diff and commit application code and shared code at the same time from the user's perspective (they need not truly be atomic).</li> <li>It seems like we should be putting application code and shared code in separate repositories.</li> <li>Subrepositories tie parent repositories to specific revisions, which we do not want.</li> </ol> <p>What am I missing here?</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USrationull
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POMonolithic vs multiple Mercurial repos for modules within a suite of related applications
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POMonolithic vs multiple Mercurial repos for modules within a suite of related applications
      1. USjenglert
      1. VTFavorite
    3. VO
      singulars
      1. POMonolithic vs multiple Mercurial repos for modules within a suite of related applications
      1. This table or related slice is empty.
      1. VTUpMod
    1. COWhat is your argument against having one big repository with everything in it? If all the code is related and should be kept in-sync with each other, why not do that?
      singulars
      1. POMonolithic vs multiple Mercurial repos for modules within a suite of related applications
      1. USjwd
    2. COCan you give us an idea of "medium-sized"? Perhaps an approximate total size of all source files in the suite? Also, #3 in your summary is unclear to me: what do you mean by "tie", and why do you not want it?
      singulars
      1. POMonolithic vs multiple Mercurial repos for modules within a suite of related applications
      1. USJoel B Fant
    3. COMy most compelling argument against having one big repository with everything in it is that if we wanted to share code with other departments via the repository, we'd have to give them access to all the code. Not necessarily a deal breaker but not great.
      singulars
      1. POMonolithic vs multiple Mercurial repos for modules within a suite of related applications
      1. USrationull
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload