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. A better way to manage this setup might be to use one repo and keep the "shared" code on one named branch and keep each of the 20 projects on separate branches. Development done in the shared branch could be merged to the project branch, but changes going in the other direction should not be merged but "transplanted" in some way after careful review and QA. /Mads ------------------------------------------------------------------------------ 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
