On 23-11-2011 12:14, Mads Kiilerich wrote: > On 11/23/2011 03:52 AM, Marvin Yan wrote: >> But in our IT team, all the 20 ERP system are come from a single >> project, we modified the original project as version A , and version B , >> and all these versions became 20 projects, in these projects, there are >> still 70 percent code are same. we call these 70% "shared" code, they >> can be modified in every project, and in other projects , a simple >> update should get these changes. >> >> in old VSS age, we use "share" function, it's very convenient, and then >> we migrated to SVN, "external" function is not as convenient as share, >> but it do works . Now we want to use mercurial, nothing helps. >> >> our require is very simple: when we modify a shared file, we should >> commit only one time, instead of modify it 20 times and commit 20 times >> in all the projects. >> >> in fact, the shared code is not a seperated project, they are functions, >> classes, or some logic files. (for example, may be a workflow of >> warehouse management is perfectly same of all the factories, so we keep >> the web pages as shared file. ) make them as sub-repos really make no >> sense, but is there other mechanisms in mercurial to do such things? > > I hope you have some kind of QA process in place so a careless commit > only tested in one context doesn't break the 19 other contexts > immediately. It is not a good idea to let every new changeset show up > immediately. I think it would better to let your QA or release > management team test and update the 20 repos for example once a week, or > you could leave it to the lead developer of each project to pull a new > version on demand. > > If you really don't want the strong version control promised by > Mercurial subrepos then you should use some other mechanism for managing > your repositories.
For instance, my work place, Edlund, uses a somewhat looser coupled concept where we have forest (called solutions) of repositories (called modules) corresponding to each customer, with cross-module branches but without the snapshot-semantic that subrepos has. This is then supported by a tool, repoman, which we've built on top of Mercurial. The scenario sounds somewhat similar to OP's. -Sune ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Tortoisehg-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
