Confirmed users
329
edits
Multiple Project Repositories: Difference between revisions
Jump to navigation
Jump to search
Expand contributor's multi repo section
m (minor updates) |
(Expand contributor's multi repo section) |
||
| Line 33: | Line 33: | ||
Summary: A user who wants to contribute to multiple divergent areas within the Mozilla codebase will need to have half a dozen repositories checked out. | Summary: A user who wants to contribute to multiple divergent areas within the Mozilla codebase will need to have half a dozen repositories checked out. | ||
=== Losing a single unified work area === | |||
Not a problem. I first tried to keep all of my changes in one mq repository, shuffling patches constantly, but I eventually discovered that I needed half a dozen personal repositories to keep separate things separate -- and this was all for work under the js/src tree. So from my experience, sprouting lots of repos is the Right Way anyway. | Not a problem. I first tried to keep all of my changes in one mq repository, shuffling patches constantly, but I eventually discovered that I needed half a dozen personal repositories to keep separate things separate -- and this was all for work under the js/src tree. So from my experience, sprouting lots of repos is the Right Way anyway. | ||
| Line 43: | Line 45: | ||
Warning: I haven't actually tried the multiple-head approach above, so I don't know what problems may arise in practice. | Warning: I haven't actually tried the multiple-head approach above, so I don't know what problems may arise in practice. | ||
=== Disk space for source === | |||
Assuming mercurial and your OS supports it, hard links resolve this fairly well, as discussed above. (Mercurial on all Linux filesystems, and Windows' NTFS filesystem, hard link your clones for you. So that's pretty good coverage.) | |||
Backups do not necessarily check for hard links, and may explode in size. Also, Mercurial doesn't do a great job of sharing the history data for files that change across clones. And the links tend to get broken during regular usage. (hg relink helps recover from this, but is a slow and manual step.) | |||
=== Disk space and build times for obj dirs === | |||
You may have to share obj dirs across repos. This preserves single-repo disk usage and build times (especially if using ccache), but adds complexity. It doesn't really decrease the chance of having a ready-to-go build for any particular area you might want to work on, because with a single mq-controlled repository you're constantly clobbering your old builds anyway. | |||
== Merge Nightmare == | == Merge Nightmare == | ||