tag:blogger.com,1999:blog-29194345.post1936643105705748158..comments2023-10-26T07:30:05.047-07:00Comments on Code Intensity: SVN Externals are Evil; Use Piston or BraidChrishttp://www.blogger.com/profile/14204551800123292694noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-29194345.post-45548396938156627632009-08-30T04:50:13.131-07:002009-08-30T04:50:13.131-07:00your piston link may be invalid. the new one could...your piston link may be invalid. the new one could be http://piston.rubyforge.org/.pisinoreply@blogger.comtag:blogger.com,1999:blog-29194345.post-22125013176587001192009-06-04T06:47:00.162-07:002009-06-04T06:47:00.162-07:00SVN externals are evil when you need to modify som...SVN externals are evil when you need to modify some code in them and you don't have sufficient permissions. <br /><br />I'm also looking at moving to GIT but as yet have not made the transition.Philhttp://www.idontplaydarts.comnoreply@blogger.comtag:blogger.com,1999:blog-29194345.post-59134532262963283512008-05-07T21:44:00.000-07:002008-05-07T21:44:00.000-07:00Anonymous: I think your move to Mercurial will be ...Anonymous: I think your move to Mercurial will be great. I am actually almost 100% moved to Git now. I see people say it's complex, but honestly, I don't get that. It seems, for standard workflows, to be almost no different than using SVN or others. And, for things like branching and merging, it is far easier. There are a lot of more complex, powerful things you can do too, that take a bit more study, but for your typical day-to-day work, it seems definitely no harder.<BR/><BR/>With Git, what I use now is its "submodules", which is a built in feature, that is roughly comparable to svn:externals. This works for similar cases as svn:externals, but in cases where I need to modify the external, I then just clone the external item's Git repository, and then submodule that clone. This allows me to make code changes at will, but still get the benefit of the submodule where it's just referencing the "external" code. Submodules can use branches and so on, so you have a lot of choices on the approaches here.<BR/><BR/>Finally, throw GitHub on top of it all and you really have a stellar system. I use GitHub for all my projects, yet none of them are public projects (yet). It's still a great additional layer on top, plus the coordination with other people's Git/GitHub repos is really great.<BR/><BR/>Anyway, either way you slice it, the word is out, and SVN's days are numbered (although at this time, that's still a high number ;-)Chrishttps://www.blogger.com/profile/14204551800123292694noreply@blogger.comtag:blogger.com,1999:blog-29194345.post-49625973523198072842008-05-07T19:01:00.000-07:002008-05-07T19:01:00.000-07:00We have a suite of large C++ projects, with many s...We have a suite of large C++ projects, with many shared modules between them. We have been using svn:externals to assemble a project tree from modules, but this creates its own headaches when (for example) you want to tag a release (comprising all modules). So thanks for the tip on Piston, it looks like it may do what we need.<BR/><BR/>Ultimately we will be migrating to Mercurial and using its Forest extension to manage this complexity. Subversion simply has too many limitations for us, and Mercurial is faster and more flexible. We tried git but it is way too complex.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-29194345.post-69796884919812607442008-03-12T16:00:00.000-07:002008-03-12T16:00:00.000-07:00That's actually what we had previously - and the s...That's actually what we had previously - and the svn externals were all to other repos in our SVN (mix of our own plugins, and others). But, that doesn't get around the general issues caused by svn externals. If you ever have to remove that external and put code in with the same dir name, SVN just can't seem to cope very well. The Piston approach seems to be a much nicer approach, and you could even combine it with what you mention, which is what I do - we still maintain the code as SVN repos of their own, but instead of pointing to it as an external, I use Piston. Then, if I update that code, and make a new tag or whatever, I can simply move to the new code via a "piston switch" or "piston update" (if on trunk or on a non-tagged branch, etc.).<BR/><BR/>Even cooler, is the ability with Piston to make changes, and still be able to update <I>while preserving those changes</I>. I just used that today. I have a plugin that's Pistonized. I needed to make a small tweak to it, which I had done. Then today, I needed to update that plugin code, and just used Piston to "switch" to a new tag, but it took care of merging the changes I'd made previously with the new code. Very nice. Externals won't do that.Chrishttps://www.blogger.com/profile/14204551800123292694noreply@blogger.comtag:blogger.com,1999:blog-29194345.post-79729943229146867562008-03-12T15:54:00.000-07:002008-03-12T15:54:00.000-07:00My trick, when I had to do this, was to create a n...My trick, when I had to do this, was to create a new repo, check in the forked plugin code there, and simply change the URL to point to the new repo (presumably on a tag).<BR/><BR/>Then you've effectively moved the code into your control, but you don't have to worry about plugin changes polluting your main app's repo.Justin Georgehttps://www.blogger.com/profile/00841137599327072247noreply@blogger.com