Question about auto commit
hello I have a situation, where there are two(or more) projects with its trunks, and some modules in these trunks are the same: /project1 /project1/trunk /project1/trunk/module_123 /project1/trunk/module_1234 /project1/trunk/module_12345 /project1/trunk/module_4567 /project2 /project2/trunk /project2/trunk/module_23456 /project2/trunk/module_1234 /project2/trunk/module_789 /project2/trunk/module_56789 in above example, module_1234 is identical in both project. When I change something in /project1/trunk/module_1234 I have to change it also in /project2/trunk/module_1234 (because it has to be the same) If there is more than two project this operation will take some time. What is the best way to automate such case? - create some script on client side? (each developer would use such script) - create some script on server side? (hooks, no script would be needed on developer side, but could it be done using hooks???) how such hook (probably post-commit) would looks like? svn update project2 svn merge -c $REV http://svn/project1/trunk/module_1234 svn commit -m "" project2 ??? - any other? Best Regards Jacek
Re: Question about auto commit
Ok, it seems to be ok but has some disadvantages: when I commit changes on either trunk, this change is made only on /share/module_1234 (the revision number of project1 or project2 will not increase). Because of the above there is no information in show log of project1/project2. The trunk history of the latest changes is very handy. Also any commit to the trunk should trigger the auto build, and in these case it won't. (unless the /share/ is also watched by the auto build tool, which is actually not a problem) > The SVN solution for this use case svn:externals ([1]). > Basically, you would have a single instance of module_1234: > /share/module_1234 > and in each project you use that module, > you define the svn:externals property to point to that module: > /project1/trunk - svn:externals = ^/share/module_1234 module_1234 > similarly for project2. > > This way, when developers checkout either trunk, > they automatically get a copy of the shared module in their working > copies. > Just make sure you read the details in [1] for possible gotchas > (like specifying revs and committing the externals separately) > > Itamar. > > [1] http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html > > On Mon, Apr 19, 2010 at 10:41 AM, wrote: > >> hello >> >> I have a situation, where there are two(or more) projects with its >> trunks, >> and some modules in these trunks are the same: >> >> /project1 >> /project1/trunk >> /project1/trunk/module_123 >> /project1/trunk/module_1234 >> /project1/trunk/module_12345 >> /project1/trunk/module_4567 >> >> /project2 >> /project2/trunk >> /project2/trunk/module_23456 >> /project2/trunk/module_1234 >> /project2/trunk/module_789 >> /project2/trunk/module_56789 >> >> in above example, module_1234 is identical in both project. >> When I change something in /project1/trunk/module_1234 I have to change >> it >> also in /project2/trunk/module_1234 (because it has to be the same) >> If there is more than two project this operation will take some time. >> >> >> What is the best way to automate such case? >> >> - create some script on client side? (each developer would use such >> script) >> - create some script on server side? (hooks, no script would be needed >> on >> developer side, but could it be done using hooks???) >> how such hook (probably post-commit) would looks like? >> svn update project2 >> svn merge -c $REV http://svn/project1/trunk/module_1234 >> svn commit -m "" project2 >> >> ??? >> >> - any other? >> >> >> Best Regards >> Jacek >> >> >> >
Re: Question about auto commit
> > On Apr 19, 2010, at 03:53, ja...@smars.pl wrote: > >> Ok, it seems to be ok but has some disadvantages: >> >> when I commit changes on either trunk, this change is made only on >> /share/module_1234 (the revision number of project1 or project2 will not >> increase). >> Because of the above there is no information in show log of >> project1/project2. > > I guess you have each project in its own repository? Ok. Actually all projects are in single repo but I wonder about making them separately (are there any advantages of it?) > > The strategy is that each project, and each module, has its own release > schedule. So if you make a change to module_1234, then you release (i.e. > tag) a new version of module_1234. And then, as a second step, for each > project that uses module_1234, you update that project to use that new > version of that module. This implies that the external defined in each > project does not refer to the module's trunk but to a tag of that module. > So at minimum you'd update the external definition to point to the new > version of the module. Possibly, you'd also need to make other changes to > the project, if you've changed the module's interface or added new > functionality to the module that you now want to use in the project. > In my approach: Any changes to any module in the tunk does not mean a release of the new version (I do not create any tag after each commit to the trunk) Trunk is being "stabilized" until it is buildable and simple tests are passed. Then I release such trunk by making a branch or/and tag. If the build fails(or some test wont pass), I can do a simple show log on trunk of such project and see who broke it. not sure if it is the optimal way... >> The trunk history of the latest changes is very handy. >> Also any commit to the trunk should trigger the auto build, and in these >> case it won't. (unless the /share/ is also watched by the auto build >> tool, >> which is actually not a problem) > > Also solved by the above since now there is a commit in the project's > repository whenever you switch to a new version of the module. >
