tag:blogger.com,1999:blog-28529319510462108112024-03-18T22:09:23.612-05:00svn commit ./meUseful information about using Subversion and SubclipseUnknownnoreply@blogger.comBlogger34125tag:blogger.com,1999:blog-2852931951046210811.post-40840895053694278322012-06-28T11:58:00.003-05:002012-06-28T12:07:19.697-05:00Eclipse p2 Frustrations<br />
Eclipse p2 continually frustrates me. For years I have been working around it and we have been peacefully coexisting. I recently tried to dip my toes back in the water to see if I could better understand it and use it better. I have what seems to me a simple situation that would be common in the Eclipse world but I cannot find a satisfactory solution.<br />
<br />
I have an <a href="http://desktop-eclipse.open.collab.net/" target="_blank">Eclipse feature</a> comprised of many plugins. These are intended to be installed in an Eclipse-based IDE and the assumption is that it should be possible to install it via the update manager UI of Eclipse or the Marketplace client. My feature extends a lot of other Eclipse plugins that need to be installed. For example, it needs Subclipse, Mylyn, GEF and several other plugins. Some of these are hosted on eclipse.org and some are on other sites. I want someone to be able to install my feature and have any other features that are needed discovered and installed automatically and seamlessly.<br />
<br />
The peaceful coexistence I have talked about is that I have been able to make this work by hosting all of the dependencies on the same update site as my feature. This is labor intensive and kind of annoying but it worked so that is what I did. I would much prefer to just publish a site that contains only my features and whatever pointers are needed for Eclipse to go get the rest of the plugins. I cannot figure out any way to do it and I have not seen any other sites that do this successfully so I just assume Eclipse cannot do this.<br />
<br />
Am I wrong in thinking this should not only be possible, but easy?<br />
<br />
I have tried adding associate sites to the site.xml. That did not do anything. I tried <a href="http://divby0.blogspot.com/2011/02/simplifying-p2-process-part-4-using.html" target="_blank">adding a p2.inf file</a> to my feature JAR's. I could see that the <a href="http://wiki.eclipse.org/Equinox/p2/Publisher#UpdateSite_Publisher_Application" target="_blank">UpdateSitePublisher</a> added the instructions to the content.xml file, but it appears to add them in a place that would only be applied after my feature is installed. So it does not help for my scenario of needing to add these sites to find required dependencies. I am at a loss and about to go back to my ugly workaround.Unknownnoreply@blogger.com12tag:blogger.com,1999:blog-2852931951046210811.post-11053351571472389322011-08-03T15:48:00.002-05:002011-08-03T15:53:17.199-05:00Debugging Eclipse Indigo plugins on OSXI do not why this took me so long to figure out, but I have been having a problem with Indigo that whenever I fire up the Eclipse Runtime workbench to debug a plugin it would crash almost immediately. At first, I thought it had something to do with my plugins, but eventually I took the time to do a clean install without any of my plugins and saw the problem just by creating a simple demo project in the runtime. Since I already had a working Helios installation, I just shrugged and went back to using that for now and set the problem aside.<div><br /></div><div>Well, last week I got a new Macbook Air with Lion preinstalled and so I am setting up a new system from scratch. This time I only have Indigo installed and lo and behold I am still seeing the same problem. Realizing that there must be a simple explanation, I now looked closer and see that there is a simple explanation. For some reason, on Indigo when it Eclipse creates your default configuration it is not including the PermGen settings by default. So I was just crashing due to not enough PermGen space errors. Pretty obvious, it has just been a long time since I had seen these problems.</div><div><br /></div><div>Adding "-XX:MaxPermSize=256m" to the -vm arguments in my Runtime Configuration has everything working great again.</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2852931951046210811.post-66198810590232099592011-04-25T12:50:00.004-05:002011-04-26T15:36:56.585-05:00I've been hacked!I was hacked today (or at least I learned of it today). Early this AM a SPAM was sent from my GMail account to all of the Contacts in my GMail -- which I believe is any address I have ever received an email from. Given all of the mailing lists I am on, this is a decent number of addresses. Since the email was <a href="http://www.dkim.org/">DKIM-verified</a> to come from GMail and it went to all my contacts, I have to assume someone was able to successfully login to my GMail. I have since changed my password a couple times, and turned on the <a href="http://googleblog.blogspot.com/2011/02/advanced-sign-in-security-for-your.html">2-factor authentication feature</a>. I would highly recommend everyone do this with their Google account if they have not. I also changed my password on every site I can think of, just for safe measure.<div><br /></div><div>How did this happen? I have no way to know for certain, but I have a theory. The Sony Playstation Network has been <a href="http://www.engadget.com/2011/04/23/playstation-network-outage-blamed-on-external-intrusion-conti/">down for several days now</a> due to some kind of attack. My username for PSN was my GMail account and I was stupid enough to use the same password (or at least they matched last week, I may have recycled back to it). I mainly use PS3 and PSN for Netflix streaming. I suspect that when the site was first down last week that intruders were intercepting logins and they got the username and password. My main reason to doubt this theory is that hacking PSN seemingly was sophisticated to do, so why would they use the information they stole in such an amateurish way as to send an obvious SPAM that alerted me to the problem? I have to think they downloaded all my email and information before they did this. I wonder why they did not also change my password as it seems like they could have done so.</div><div><br /></div><div>It is fairly disconcerting to wonder what private information, such as credit card numbers, that I might have in my GMail archive. For now, I at least think I have safely updated all of my accounts so that the passwords are different on every site.</div><div><br /></div><div><i>Update (2011-04-26)</i>: Sony has now pretty much confirmed that this all originated with the hack of PSN. See this blog post: <a href="http://blog.us.playstation.com/2011/04/26/update-on-playstation-network-and-qriocity/">http://blog.us.playstation.com/2011/04/26/update-on-playstation-network-and-qriocity/</a> Of course it was still stupid on my part to use my GMail password anywhere outside of GMail.</div><div><br /></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2852931951046210811.post-87295499397075666912011-01-03T12:34:00.003-05:002011-01-03T12:44:59.227-05:00Open Letter to WANDisco<div>Shortly before we all went away on our Christmas holiday, one of the companies that sponsors developers in the Subversion community, WANDisco, delivered a big fu#k you to the rest of the community in the form of a <a rel="nofollow" href="http://blogs.wandisco.com/2010/12/20/shaking-up-subversion-by-listening-to-the-user-community-and-then-committing-to-do-the-work/">press release</a> and <a rel="nofollow" href="http://wandisco.com/php/pr.php?rss=0&prdate=2010-12-20">blog post</a> from their CEO Dave Richards.</div><div><br /></div><div>I commend my fellow members of the Subversion PMC for being able to take a deep breath and wait a couple weeks to respond with a cool head. Had it been up to me alone, I am sure we would have said something that felt good at the time but that we regret later. You can read the official response here on the Apache Software Foundation blog:</div><div><br /></div><a href="https://blogs.apache.org/foundation/entry/apache_subversion_to_wandisco_1">Apache Subversion to WANdisco: +1 on the code contributions, -1 on the attitude</a><div><br /></div><div>I was, and am, deeply offended by Dave Richards and WANDisco in general. Their business model seems to be to issue press releases rather than actually doing stuff. In my experience, companies that choose to issue press releases BEFORE they start working on something are usually to be ignored and I think that is the case here too. The difference is that WANDisco is attempting to portray themselves as leading the Subversion community and as such that they are speaking for the community. As the blog post from the Subversion PMC illustrates, they neither lead the community nor are the welcome to speak for it.</div><div><br /></div><div>That said, I get it. No one knows or cares who WANDisco is and by issuing press releases and generating controversy a few more people will now have heard of you. Congratulations. Bully for you. However, in the process your actions are only damaging the product and community you claim to care so deeply about. This reveals your true motives.</div><div><br /></div><div>If you are so desperate for attention that you feel the need to issue press releases we probably cannot stop you. If you absolutely have to to issue a press release to try to garner some attention, then why could you not simply issue something that says "Hey we think features X, Y and Z are important and we wanted to let you know that we intend to direct our resources to work on those features." I could live with that even though I would rather see you work on the features before you crow about it. As it stands, just as you did a <a href="http://www.cmcrossroads.com/index.php?Itemid=100152&catid=101:news-and-announcements&id=13065:wandisco-presents-new-initiatives-for-the-subversion-open-source-project-&option=com_content&view=article">year ago</a> with the Obliterate feature, you are just setting your people up for failure. You have declared that you are going to implement new features that the Subversion committers that work for you already know cannot be solved in the near term. You have brought no new ideas to the table nor any idea how any of the known obstacles that have blocked these features will be overcome. To top it off you have attempted to slap a release date on it. Good luck with that.</div><div><br /></div><div>I really hope that we implement some of the features in your list and it would be even better if we can get some of them done in 2011. Most of your list was already on the roadmap we published last year. Unfortunately, the way you are going about this is not going to help any of that happen and if we do have some success it will likely be in spite of your efforts not because of them.</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2852931951046210811.post-76610221304247488002010-06-25T08:25:00.003-05:002010-06-25T08:36:35.741-05:00Eclipse 3.6/Helios key-bindings changes?We have had several Subclipse users <a href="http://subclipse.tigris.org/issues/show_bug.cgi?id=1159">point out</a> that their key-bindings for Subclipse commands are not working in Helios. Does anyone have any ideas/pointers they can give as to what has changed that would make this feature stop working?<div><br /></div><div>Key-bindings are working for the core Eclipse plugins, so it is not like the entire feature is broken, it just seems that something has changed. Usually Eclipse release are very good at backwards compatibility. We still are able to provide a single version of Subclipse that works on Eclipse 3.2 and higher. I would hate to have to provide a specific version for Eclipse 3.6 if we can avoid it. We still get lots of downloads for our Eclipse 3.0 version!</div><div><br /></div><div>[Update] - It looks like a user figured out a <a href="http://subclipse.tigris.org/issues/show_bug.cgi?id=1159">cure for the problem</a>. Now we have to figure out what to change in Subclipse to do this automatically.</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2852931951046210811.post-44156037277797778912009-06-23T15:36:00.004-05:002009-06-23T15:51:54.130-05:00Subclipse and Eclipse 3.5/GalileoWith the Eclipse 3.5 final release now available, I thought it would be good to get a post up for Subversion users that are looking to install this release. Subclipse works great in Eclipse 3.5 and is easy to install. There are two versions of Subclipse available with support for Eclipse 3.5.<br /><br /><a href="http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA">Subclipse 1.4.x</a> is based on Subversion 1.5 client API<br /><a href="http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA">Subclipse 1.6.x</a> is based on Subversion 1.6 client API<br /><br />Install the version of Subclipse based on the version of Subversion you want to use. This is mainly an issue if you want to use multiple clients with the same Subversion working copy. If you do all of your work from Eclipse, then just grab the latest version. All Subversion 1.x clients can work with all Subversion 1.x servers. So, if possible, just use the latest version.<br /><br />OSX and Linux users need to install the <a href="http://subclipse.tigris.org/wiki/JavaHL">right version of the JavaHL library</a> (1.5 or 1.6). Most Linux distros are still providing 1.5.x, but the <a href="http://www.open.collab.net/downloads/subversion/redhat.html">RPM's from CollabNet</a> include JavaHL and install on every Linux distro that I have tried (including Ubuntu). CollabNet also provides binaries and <a href="http://www.open.collab.net/downloads/community/">JavaHL for OSX</a>.<br /><br />I maintain a wiki on the Subclipse site with detailed information about <a href="http://subclipse.tigris.org/wiki/JavaHL">getting JavaHL working on your system</a>.<br /><br />In other news, Subclipse 1.6.x now includes the <a href="http://subclipse.tigris.org/">CollabNet Merge client</a>. This was developed as part of the merge tracking feature in Subversion 1.5 and makes merging from Eclipse very easy to do and manage. The CollabNet Merge client is part of the <a href="http://desktop-eclipse.open.collab.net/">CollabNet Desktop - Eclipse Edition</a>, which includes <a href="http://www.eclipse.org/mylyn">Mylyn</a> and connectors for <a href="http://www.open.collab.net/products/sfee/">CollabNet's trackers</a>. The merge client is now also available directly for Subclipse users with no other dependencies. Users that want the full merge client, which adds the change set merge option, can install the CollabNet Desktop.Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-2852931951046210811.post-66028161339687065112007-09-21T11:03:00.000-05:002007-09-21T11:46:53.310-05:00New Subclipse Build Posted -- Dialog ImprovementsI just posted a new development build of Subclipse - 1.3.3. You can currently only get these builds as part of the <a href="http://merge-tracking.open.collab.net/">CollabNet Merge Tracking Early Adopter</a> program. The reason being that these builds require development build of Subversion 1.5 and I am coordinating these builds so that they use the same Subversion binaries (to make it easier to test).<br /><br />This new build includes some dialog UI improvements I have been wanting to make for a long time. I have really grown to like the simplicity of the CVS commit dialog and have heard comments many times about the general usability difference between the CVS plug-in and Subclipse. So the intent here is to close the gap some more and incorporate some of the same UI while maintaining the Subclipse features that we can. Here is a fairly complicated example that shows most of the features:<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgHmWx1xSIYIvkWFsNlYmyu-luRCazNbonNytvkZXuO19HMm7A3loqUcdfoIbgGFTAiQu8SKPktDy5kv3oZSDhjHN1J7tp4rG3Silg1L-iRt6bXGpBstiRiMRsRTYZad__7KgVVb-JuUjOB/s1600/commit-1.png"><img style="cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgHmWx1xSIYIvkWFsNlYmyu-luRCazNbonNytvkZXuO19HMm7A3loqUcdfoIbgGFTAiQu8SKPktDy5kv3oZSDhjHN1J7tp4rG3Silg1L-iRt6bXGpBstiRiMRsRTYZad__7KgVVb-JuUjOB/s400/commit-1.png" alt="" id="BLOGGER_PHOTO_ID_5112690103733177506" border="0" /></a><br /></div><br />There are a few of major changes.<br /><ol id=""><li>The dialog uses a wizard-style UI which is pretty common in Eclipse. This gives us a chance to include a graphic and just generally make the dialog look better.<br /></li><li>The presentation of files has changed from a table with checkboxes to the more friendly and graphical mode that CVS uses. There are three presentation models to choose from.<br /></li><li>Because we no longer have a table to show data and text we needed a way to show when there are Subversion property changes. We are using a second decorator to do this. Currently we only use this in these dialogs, there are no plans to do this in Eclipse views.<br /></li><li>The biggest change is that you now have to right-click and use Remove from view to not commit something. You used to be able to uncheck a check-box.</li></ol><div>Earlier this year I wrote a post that detailed the <a href="http://markphip.blogspot.com/2007/01/features-of-subclipse-commit-dialog.html">Features of the Subclipse Commit dialog</a>. You can review that post if you want to compare the differences in the UI. Here is another screenshot that is a little simpler to give another taste of the changes.<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjU4WILBhhjKXYPW5ACTOtZJd6Srs22IVNPlZMbQm_GnTveJYSp4H4qCTmePBKJ7yXEqm6wMgAP26ttLl0Y_jVwtahnnJmbP0fEI58cZyJ1i7qh1xHTTHephfFXRrvTigGV0U3DzVCvLQMB/s1600/commit-2.png"><img style="cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjU4WILBhhjKXYPW5ACTOtZJd6Srs22IVNPlZMbQm_GnTveJYSp4H4qCTmePBKJ7yXEqm6wMgAP26ttLl0Y_jVwtahnnJmbP0fEI58cZyJ1i7qh1xHTTHephfFXRrvTigGV0U3DzVCvLQMB/s400/commit-2.png" alt="" id="BLOGGER_PHOTO_ID_5112691409403235506" border="0" /></a><br /></div><br />I think everyone will agree the dialog looks better. I think where there might be some controversy is in how you decide to not commit a certain file. This new approach is definitely optimizing for the scenario where you typically commit everything in the dialog. Users that work mostly from the Synchronize view, as an example, should really like this better.<br /><br />Personally, I find this approach more usable. Even though it is a little more difficult to right-click and remove something than it was to uncheck it, the fact that the item no longer shows up in the view makes it more obvious what is going to be committed.<br /><br />The Revert and Lock dialogs got the same treatment:<br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhffJLhTTPb3D9Y-unpOUzeH67yGGiSg9i0BFjOWEA0fBpIh71h-EovE-MA9OXVPzIYSWZVNHr-YpxbrN25qfukQC7m9FmN7BGV-PnyfS_14alrYjLKuHkdu4iauGkJHPT0-Q9z4qGTJgNc/s1600/revert.png"><img style="cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhffJLhTTPb3D9Y-unpOUzeH67yGGiSg9i0BFjOWEA0fBpIh71h-EovE-MA9OXVPzIYSWZVNHr-YpxbrN25qfukQC7m9FmN7BGV-PnyfS_14alrYjLKuHkdu4iauGkJHPT0-Q9z4qGTJgNc/s400/revert.png" alt="" id="BLOGGER_PHOTO_ID_5112693075850546370" border="0" /></a><br /></div><br />Other dialogs like Switch and Create Branch/Tag also received the new wizard look. Please give these builds a try and let me know what you think. The best places to reply would be the Subclipse users@ mailing list or in the issue tracker for this <a href="http://subclipse.tigris.org/issues/show_bug.cgi?id=682">issue 682</a>.</div>Unknownnoreply@blogger.com23tag:blogger.com,1999:blog-2852931951046210811.post-1025023470027413072007-09-18T19:00:00.000-05:002007-09-18T19:55:32.758-05:00Introducing the CollabNet Merge ClientI have not posted to this blog in quite a while. I have been thinking about using it to blog some personal thoughts (like on the Red Sox) but I know it is syndicated in a few places for its Subversion/Subclipse content so I haven't. Instead, I have been doing all of my Subversion blogging over on the <a href="http://blogs.open.collab.net/svn">Submerged</a> blog at <a href="http://www.open.collab.net/">openCollabNet</a>.<br /><br />It has been a busy summer. I have been more involved in the Subversion community than at any time in the past. Earlier in the summer I was made a full committer which was a proud moment and I have been doing a lot of work to help drive us to the final 1.5 release. Beyond all of that, what I have really been working on the most, however, is the development of a new GUI merge client for Subversion to coincide with the Subversion 1.5 release. Yesterday, we officially announced the client and released an early version. You can read the <a href="http://blogs.open.collab.net/svn/2007/09/subversion-merg.html">blog post here</a>, or skip right to the <a href="http://merge-tracking.open.collab.net/">details here</a>.<br /><br />The CollabNet Merge Client is built on top of Eclipse and Subclipse and has the simple goal of making merge easier. I think it does that and a lot more. It has really turned out great. There are <a href="http://merge-tracking.open.collab.net/alm-process/2-Documents/Merge%20Client%20Overview/">details on the web site</a>, so I will not reiterate them here.<br /><br />As part of developing this client, we have also made a lot of <a href="http://subclipse.tigris.org/subclipse_1.4.x/changes.html">really nice enhancements</a> to Subclipse. We have focused on taking advantage of all of the great new features that are coming in Subversion 1.5 and also on general usability. I think the final result is going to be great.<br /><br />The Subversion community is working hard to get the Subversion 1.5 release process started by mid-October so that it can be GA in December. The GA of Subclipse 1.4 and the CollabNet Merge Client will be at the same time. <br /><br />If you use Subversion and Eclipse, even if you do not use Eclipse, I would encourage you to check this out and give it a try. It requires using the latest build of Subversion 1.5 on the client, but that is not as risky as it sounds, and we will be refreshing the client with new builds as needed. We are also providing Linux JavaHL binaries to make it easier for Linux users to try. Currently only OSX users are shut out, which is ironic because I do all my development on OSX. We could probably make a 1.5-trunk installer for OSX but it would take some work to make it co-exist with the <a href="http://downloads.open.collab.net/binaries.html">existing 1.4.4 client</a> for OSX. I know Jeremy has been busy so I have not asked him to do the work required. At worst this problem will go away when 1.5 is GA, but hopefully we will have something available before then.<br /><br /><span style="font-weight: bold;">CollabNet Desktop - Eclipse Edition</span><br /><br />There was one other aspect to this, yet another thing I have not blogged about. That is the <a href="http://eclipse.open.collab.net/">CollabNet Desktop - Eclipse Edition</a>. This is a unified set of tools to access all CollabNet products from Eclipse. We include Subclipse for accessing CollabNet Subversion repositories. There is also a small UI layer on top of this to integrate into the CollabNet perspective and sites view. <br /><br />It also includes connectors for <a href="http://www.eclipse.org/mylyn">Mylyn</a> to integrate the issue trackers available in <a href="http://www.collab.net/products/enterprise_edition/">CollabNet Enterprise Edition</a> (CEE) into Eclipse. There are a lot of popular open source sites that use CEE such as <a href="http://www.tigris.org/">tigris.org</a>, <a href="http://www.java.net/">java.net</a>, <a href="http://www.openoffice.org/">openoffice.org</a>, <a href="http://www.netbeans.org/">netbeans.org</a>, <a href="http://dev2dev.bea.com/">dev2dev.bea.com</a> etc. Now the issue trackers for all of these sites are available in Eclipse and Mylyn.<br /><br />We are also currently working on a Mylyn connector for the issue tracker in <a href="http://www.collab.net/products/sfee/">SourceForge Enterprise Edition</a>, which is now a CollabNet product. Note: This is not the same product that runs on sourceforge.net.<br /><br />Last but not least, we also provide integration and access to <a href="http://www.collab.net/products/CUBiT/">CollabNet CUBiT</a>. This is a really cool product and the integration came out great. CUBiT allows you to virtualize your build and test environments. From Eclipse, I can provision a server in our CUBiT environment, this includes picking the operating system to run and possibly a set of other components I want to install such as MySQL, Apache etc. These servers are accessible via SSH, and the CollabNet Desktop client makes it simple to access the servers and setup port forwarding to access services running on the servers etc. We integrated the SSH Terminal from the Eclipse <a href="http://www.eclipse.org/dsdp/tm/">DSDP/TM</a> project to provide terminal access. We also support launching external clients but none are required.<br /><br />I use CUBiT to dynamically provision servers to test Subversion releases (which I have to test on Windows, Linux and Solaris), but most people are using it to build, run and debug server-based web applications. Anyway, the CollabNet Desktop was just another of the many things I have been working on this summer and it <a href="http://eclipse.open.collab.net/new/index.html">went GA</a> a few weeks ago.<br /><br />It has been a busy summer.Unknownnoreply@blogger.com9tag:blogger.com,1999:blog-2852931951046210811.post-54615460949573771332007-06-02T12:44:00.000-05:002007-06-02T13:01:22.700-05:00Unstoppable SubversionLots of Subversion news this week as the popularity and adoption continues to soar. <br /><br />First, Forrester Research released their latest Forrester Wave where they analyzed the Software Configuration Management marketplace. For the first time, they included Subversion in their analysis, and what do you know, but Subversion actually came out on top for standalone SCM! They also analyzed integrated change management systems and included Subversion. It did surprisingly well considering that it really does not specifically address that space. You can <a href="http://www.collab.net/forrester_wave_report/index.html">download a copy of the report</a> from CollabNet.<br /><br />Next, the latest SecuritySpace.com numbers came out for the month of May and Subversion adoption continues to soar. <a href="http://subversion.tigris.org/svn-dav-securityspace-survey.html">See this chart for more information</a>.<br /><br />Finally, I participated in a webinar this week with Carey Schwaber of Forrester and my CollabNet colleague Auke Jilderda. You can <a href="http://www.collab.net/webinar17/">view a replay here</a>. This was my first time doing a webinar. I will probably try to make a post about the experience. It was a lot of work for 10 minutes and of course I screwed up the slides when control was transitioned to me. That really flustered me but I recovered. I just got up the courage to watch the replay this AM and it was a lot better than I thought, I actually came in at exactly 10 minutes. I am not sure how eager I will be to do another one anytime soon though because it just took up too much time to prepare. It is hard to do these well if you are not a pro speaker because you are so constrained for time. Anyway, the first 20 minutes of the webinar is Carey going over her report, the criteria used and an overview of SCM for distributed development teams. I then gave a quick overview of Subversion and why it is popular before covering the upcoming 1.5 release and some of its features. Auke then finished things off with an overview of the merge tracking feature which is the defining feature for 1.5. We then concluded with a fairly lengthy Q&A session. There were over 500 people connected which I understand to be a very large audience for one of these events. Clearly interest in Subversion is skyrocketing.Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-2852931951046210811.post-58955888606263798982007-05-15T12:47:00.000-05:002007-05-15T13:12:46.367-05:00Subversion binaries for OS XI am pleased to report that we are now providing <a href="http://downloads.open.collab.net/binaries.html">OS X binaries</a> (including JavaHL) on <a href="http://www.open.collab.net/">openCollabNet</a>. This is an issue I raised before and soon after beginning employment at <a href="http://www.collab.net/">CollabNet</a>, so I am glad to see it become a reality. Lack of a complete binary for OS X (including the JavaHL library) was a bit of a problem since Subversion 1.4 was released. There were some command line packages available, but nothing with JavaHL. I know this caused pain for a number of <a href="http://subclipse.tigris.org/">Subclipse</a> users.<br /><br />Thanks goes to <a href="http://blogs.open.collab.net/svn/2007/05/universal_mac_o.html">Jeremy Whitlock</a> for investing his own time and effort to get a Universal Build created, as well as learning the ins and outs of Mac packaging. I have been running this package on my Mac (which I now work on most of the time) for several weeks.<br /><br />The other part of this news is that we are going to launch a project on openCollabNet to be the home for "community-driven" binaries. Basically, we can provide the bandwidth to host the downloads as well as community forums to solicit feedback etc. CollabNet does not have the resources to officially support every operating system users might be using, but this gives us a way to assist the community in providing quality binaries and also can allow us to gauge interest in the operating systems we are not officially supporting. I will follow-up to this post when the project launches.<br /><br />In the mean time, I hope all you Mac users out there will download these binaries and try them out. You can post any questions or issues in the <a href="http://subversion.open.collab.net/servlets/ForumMessageList?forumID=43">Subversion users forum</a> on openCollabNet.Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-2852931951046210811.post-65971341423911225452007-03-30T20:54:00.000-05:002007-03-30T21:09:51.622-05:00Subversion blog posts to readI have been real busy with the new job and have not had time to blog. When I have had some time, it went into blogging over on the <a href="http://blogs.open.collab.net/svn/">Submerged</a> blog. Anyway, here are some links to some good blog posts I have seen recently about Subversion.<br /><br />On the Submerged blog:<br /><br /><a href="http://blogs.open.collab.net/svn/2007/03/computing_the_d.html">Computing the Differences Between Tags</a> by yours truly :)<br />In this post I show the new svn diff --summarize command and how you can use it to get a list of files that changed between two repository locations.<br /><br /><a href="http://blogs.open.collab.net/svn/2007/03/authz_and_anon_.html">Authz and Anon Authn Agony</a> by Mike Pilato<br />In this post Mike explains a difficult problem you can run into when you want to provide anonymous access but also have private folders within the repository structure.<br /><br /><a href="http://blogs.open.collab.net/svn/2007/03/multiple_subver.html">Multiple Subversion Repositories?</a> by Guido Haarmans<br />This post touches on the issue of having multiple replicated repositories to support globally distributed development. More specifically, why you may not really need this with Subversion as you do with other tools I will not mention.<br /><br /><a href="http://blogs.open.collab.net/svn/2007/03/subversion_ldap.html">Subversion LDAP Authentication with Apache</a> by Jeremy Whitlock<br />Jeremy gives a primer on how to configure Apache to authenticate users via an LDAP directory, such as Microsoft Active Directory.<br /><br /><a href="http://blogs.open.collab.net/svn/2007/03/how_subversion_.html">How Subversion Conserves Disk Space</a> by Guido Haarmans<br />This is a high-level overview of how the Subversion repository stores your data.<br /><br />Finally, I have been meaning to link to another set of posts I have looked at. On his blog <a href="http://www.trajiklyhip.com/blog/index.cfm">TrajicklyHip</a>, Aaron West has written a whole series of detailed posts about setting up a Subversion environment and then working with various clients. He has good links within the posts themselves, so I will just link to my favorite, the one about <a href="http://www.trajiklyhip.com/blog/index.cfm/2007/3/15/Part-5-Accessing-Subversion-Repositories-With-Subclipse">Subclipse</a>. :) I am fairly experienced with Subversion and these posts are aimed at getting people started, so I cannot say that I have poured over every word in detail. That being said, it all looks quite well done and what I read was accurate. I would recommend you check it out.Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-2852931951046210811.post-12873703669159328152007-03-15T10:06:00.000-05:002007-03-15T10:15:15.692-05:00First blog post and article on openCollabNetI have agreed to participate in the <a href="http://blogs.open.collab.net/svn/">Submerged</a> blog on <a href="http://open.collab.net/">openCollabNet</a> and made my <a href="http://blogs.open.collab.net/svn/2007/03/run_svnserve_as.html">first post</a> recently. I guess they did not read this blog too closely and notice my penchant for really long posts. Anyway, we decided to make the post into <a href="http://subversion.open.collab.net/articles/svnserve-service.htm">an article</a> instead. The article is about installing the svnserve server option to run as a Windows service and you can find it <a href="http://subversion.open.collab.net/articles/svnserve-service.htm">here</a>.<br /><br />My <a href="http://blogs.open.collab.net/svn/2007/03/run_svnserve_as.html">first blog post</a> then just became an introduction to the article. You can find that post <a href="http://blogs.open.collab.net/svn/2007/03/run_svnserve_as.html">here</a>. If you have any comments on the article, you can leave them on <a href="http://blogs.open.collab.net/svn/2007/03/run_svnserve_as.html">the blog post</a>. (Yes, that is four links to the same post if you are counting).<br /><br />In the future, I will probably do more of my Subversion-specific posts on the <a href="http://blogs.open.collab.net/svn/">Submerged</a> blog and do the Subclipse posts here. I will figure it out as I have things I want to write about.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2852931951046210811.post-4208440604646926542007-03-07T16:03:00.000-05:002007-03-07T18:56:15.828-05:00Incorrect Article about me at EclipseZoneThere was an article posted today at EclipseZone (which I am not going to link to) announcing that Subversive has been approved as an Eclipse project. Congratulations to them, although this actually happened a couple of months ago so I do not know why it is news. Anyway, the article includes the following quote:<br /><blockquote>Since Mark Phippard has been quoted as joining Polarion on a flyer included in the EclipseCon information pack, perhaps the combination of the existing skills and technology will finally bring kosher subversion support for Eclipse by default.</blockquote>Even worse is that this same statement has been included in the two-sentence blurb that gets repeated in aggregators like Planet Eclipse.<br /><br />This is completely untrue.<br /><br />However, I have recently started a new job at <a href="http://www.collab.net/">CollabNet</a>, which I am very excited about, and will eventually blog about in more detail. I am assuming that the author of the post somehow got confused about this detail. CollabNet, as well as myself, are very committed to Subclipse and will continue to ensure that it is the best provider of support for Subversion in the Eclipse IDE. In addition, CollabNet provides support for Subclipse in their <a href="http://www.collab.net/support/index.html">Subversion support</a> packages available at <a href="http://www.open.collab.net/">openCollabNet.</a><br /><br />By the way, the Subversive project being provisioned at Eclipse.org, does not mean that the <a href="http://www.eclipse.org/proposals/svn/">Subclipse-based</a> proposal cannot also be provisioned. Although eventually there does have to just be one project, it is still early in the process. Our proposal got put on hold while I was looking for a new job. I could have advanced it to the next stage back in late November but decided not to. Once the dust settles on new job at CollabNet I will provide more updates on the proposal.<br /><br /><span style="font-weight: bold; font-style: italic;">Update:</span> The text of the EclipseZone article has been updated to remove the part about me. Thanks.Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-2852931951046210811.post-85675115438246698292007-03-01T10:08:00.000-05:002007-03-01T10:20:09.043-05:00What makes an Open Source Company?One of the core Subversion developers, <a href="http://asdf.blogs.com/asdf/">Garrett Rooney</a>, posted an interesting piece entitled <a href="http://asdf.blogs.com/asdf/2007/03/what_makes_an_o.html">What makes an Open Source Company?</a><br /><br />I agree with what he wrote, so I do not have a lot of commentary to add. My definition of an open source company would primarily be based on how the company interacts with and supports open source software development. Do they have developers that significantly contribute to one or more projects? Do they engage the community, or at least allow their developers to engage the community? For me, those are the determining factors.<br /><br />By the way, Garrett was the author, now co-author with <a href="http://www.dberlin.org/">Daniel Berlin</a>, of one of the best Subversion books available: <a href="http://www.apress.com/book/bookDisplay.html?bID=10203">Practical Subversion</a>.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2852931951046210811.post-43030433913772102502007-02-28T15:18:00.000-05:002007-02-28T15:22:59.334-05:00Happy Birthday SubversionA belated Happy 3rd Birthday to Subversion and those that made it possible. One of the developer's, Mike Pilato, summarizes the history best in this <a href="http://blog.red-bean.com/pilatos/?p=63">blog entry</a>.<br /><br />I knew about the birthday from some entries to the Subversion mailing list, but I did not know about Mike's blog entry until I saw a link to it on the <a href="http://www.open.collab.net/">OpenCollabNet</a> site.Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-2852931951046210811.post-31818657074736521992007-02-13T11:33:00.000-05:002007-02-11T11:27:16.000-05:00Subclipse 1.2.0 Released<a href="http://subclipse.tigris.org/">Subclipse 1.2.0</a> was released today. This is the official stable release for Eclipse 3.2 and higher. The official release includes two last minute fixes to improve support for 3.3 M5.<br /><br />This release has been in development and available via the 1.1.x release train since a little before the official Eclipse 3.2 release last June. I imagine that most Eclipse 3.2 users have been using this release since it was available. For those that have been using the 1.0.x releases, this new release contains a lot of new features and UI improvements, such as my <a href="http://markphip.blogspot.com/2006/12/subclipse-live-annotations.html">previous blog entry about Live Annotations</a>. The <a href="http://subclipse.tigris.org/subclipse_1.2.x/changes.html">full changelog is available here</a>.<br /><br />One note to those that try to update and do not see the release. By default, the Eclipse update mechanism will not show you an update which increments the minor version number. So you either need to repeat the <a href="http://subclipse.tigris.org/install.html">first time install instructions</a>, or view the <a href="http://subclipse.tigris.org/upgrade.html">upgrade instructions on this page</a>, which show you how to change the Eclipse preference that controls this.Unknownnoreply@blogger.com8tag:blogger.com,1999:blog-2852931951046210811.post-83481206997358434732007-02-01T20:08:00.000-05:002007-02-01T20:27:44.876-05:00Subclipse 1.1.10 ReleasedSubclipse 1.1.10 was released today. Details can be found in the <a href="http://subclipse.tigris.org/subclipse_1.2.x/changes.html">changelog</a>.<br /><br />There are several changes in this release that should address the most common problems reported of late. Most of those are solved by the inclusion of the Subversion JavaHL 1.4.3 libraries and the SVNKit 1.1.1 library. Each of these has several fixes that were affecting Subclipse users.<br /><br />There was also further refinement to how we handle read only files and the lock dialog when the validateEdit() method is called. This problem really impacted users of the Rational 7.0 IDE's as it seems a lot of their code somehow explicitly calls validateEdit() and bypasses the normal Eclipse ResourceRuleFactory mechanism that should be filtering out any items that are not read-only in the file system. Anyway, with the help of some of our users that were able to test the changes, we seem to finally have all of the scenarios working properly.<br /><br />Finally, I have a feeling that the next release will finally be the long-awaited 1.2.0 release, which will become our new stable, recommended release. There have been some patches floating around for a couple of new enhancements, and if they get finalized and committed there may be a couple more releases in the 1.1.x line to stabilize those features. But right now, things have very much stabilized and if no new problems show up from this release, I think I will put out the final 1.2.0 release.Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-2852931951046210811.post-81318175809842543862007-01-25T18:23:00.000-05:002007-01-25T18:34:03.920-05:00openCollabNetJust a quick post to point you to a site that you might not know about: <a href="http://www.open.collab.net/">openCollabNet</a>. This is a site being hosted and supported by <a href="http://www.collab.net/">CollabNet</a> to provide an online community for Subversion and CollabNet users.<br /><br />It is a pretty cool site that seems to have a lot of information contained within it such as articles, forums, podcasts etc. I will probably start compiling a list of interesting links and add them to a new post in the future, but for now I would suggest you poke around the various parts of the site and you will likely find something useful.<br /><br />One of the more immediate things you might find interesting on this site is that they are providing binaries for various Subversion components and tools (such as TortoiseSVN and Subclipse) and I believe they will provide support for those binaries. Currently, I think they are only offering Windows binaries. I would really like to see them provide some for OS X as there currently are not any good sources for up to date binaries for OS X. Metissian used to provide a very nice package, but they seem to have stopped providing them. Not many user's are going to want to download and install XCode so that they can build Subversion from source, and many that do seem to run into problems with various parts of the process -- at least those that are building JavaHL. Anyway, hopefully they have OS X support on their to-do list. Linux binaries would also be nice, but at the same time I think the Linux distributions are doing a decent job providing Subversion packages that work properly, so it is slightly less urgent when compared to OS X.Unknownnoreply@blogger.com5tag:blogger.com,1999:blog-2852931951046210811.post-9265521825661944862007-01-23T12:11:00.000-05:002007-01-23T14:30:40.999-05:00How to Undo a Commit in SubversionA frequent question that is asked on the <a href="http://subversion.tigris.org/">Subversion</a> and <a href="http://subclipse.tigris.org/">Subclipse</a> mailing lists is how to undo a change once it has been committed. A variant of the same request is how to get back a file that has been deleted.<br /><br />If you need to undo a change completely, as in remove all traces it ever happened, there is really only one way to do it. You need to dump the repository up to the revision you want to remove, and then recreate and load the repository from the dump file. I will not be covering that option in any detail in this article. This article will just be about reversing the effects of a commit, as in restoring a deleted file/folder or some change to a file or set of files. Depending on the circumstances, there might be several ways you can accomplish this. For example, the svn copy command can be used to restore something that is deleted. The technique I am going to focus on in this post is called a "reverse merge". Essentially, you use the svn merge command with the revisions flipped around so that the merge command undoes the changes in the selected revisions. For command-line users, the process to do this is explained well in the Subversion book. See this section on <a href="http://svnbook.red-bean.com/en/1.2/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.undo">undoing changes</a>.<br /><br />When using a GUI tool like Subclipse, you could just use the Merge option and fill out the dialog using similar values to what you would do from the command line. However, Subclipse offers a built-in technique that makes it very easy to undo a change.<br /><br />To give proper credit where it is due, the technique that is described in this article first appeared in the <a href="http://tortoisesvn.tigris.org/">TortoiseSVN</a> product. The Subclipse feature described below is based on the TortoiseSVN feature.<br /><br /><span style="font-weight: bold;">Open the History View</span><br />The first step is to show the history of the item containing the change you want to restore. If you just want to restore the changes to one file, then select just that file. Otherwise, you can select your project or a folder so that you can undo changes to multiple files. <br /><br />If you want to restore something that is deleted, then you need to show the history of the item's parent, so that the history will show you the deletion.<br /><br /><span style="font-weight: bold;">Select the Revision(s)</span><br />Now, just select the revision, or contiguous range of revisions, that contain the changes you want to undo. Right-click and choose the option to revert the changes from those revisions:<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjtjjpacVr5ltT951cW1v4ko-PCJsD_U6lFRQKb4cok06e-ho5xufpjvedYCn8dp1Ur2qG8LwAKMYB3O-6q89HtNz5YxIT9PNJmxIkRUzDK_4d1aYJX93v-iVMHpBEQa5LmnwEapSt2FLYZ/s1600-h/undo.png"><img style="cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjtjjpacVr5ltT951cW1v4ko-PCJsD_U6lFRQKb4cok06e-ho5xufpjvedYCn8dp1Ur2qG8LwAKMYB3O-6q89HtNz5YxIT9PNJmxIkRUzDK_4d1aYJX93v-iVMHpBEQa5LmnwEapSt2FLYZ/s400/undo.png" alt="" id="BLOGGER_PHOTO_ID_5023304206361835570" border="0" /></a><br /></div><br /><br /><span style="font-weight: bold;">Review and Commit</span><br />When the option runs, it will invoke the merge command, supplying the proper parameters to do a reverse merge. Review the results of the merge and commit the changes to finish the process.<br /><br /><span style="font-weight: bold;">Partial Undo?</span><br />It would not be uncommon to only want to reverse part of the changes from a commit or series of commits. There are a couple of ways to deal with this:<br /><ol><li>Select the correct context. If you only want to undo the changes to files in a specific folder, then select that folder when you show the history. Then the merge will only undo the changes in the context of that folder and other changes in the commit will be skipped by the merge process.</li><li>Revert what you do not want. Suppose you delete five files from the same folder and want to restore one of them. You have to select the parent folder when you take the option, and this will restore all five files. When the command completes, just use the Revert option to undo any changes you do not want, and then commit the rest. The merge process only restores the change in your working copy. Nothing is forcing you to commit the results of the merge without editing it first.<br /></li></ol><span style="font-weight: bold;">Conclusion</span><br />Undoing the effects of a change in Subversion is a fairly easy process once you understand what it is that you have to do. The Subclipse and TortoiseSVN UI further simplifies the process and saves you from having to lookup and enter the revisions correctly in the merge dialog.Unknownnoreply@blogger.com7tag:blogger.com,1999:blog-2852931951046210811.post-13413661058364267772007-01-19T14:37:00.000-05:002007-01-31T13:05:41.034-05:00Enhanced Support for Branches and Tags in SubclipseThis post largely draws on content I previously wrote and posted on the <a href="http://subclipse.tigris.org/branch_tag.html">Subclipse web site</a> back in December 2005 when this feature was added to Subclipse. I have attempted to freshen the content a bit in some places and repost it here for a new audience that may not be aware of this feature.<br /><br />The issue of tags in Subversion, and how they differ from CVS, is a frequent topic on the <a href="http://svn.haxx.se/users/">Subversion users@ mailing list</a>. The same issue came up a lot on the <a href="http://svn.haxx.se/subusers/">Subclipse mailing lists</a>, especially since the <a href="http://www.eclipse.org/eclipse/platform-cvs/">CVS plug-in</a> in Eclipse handles branches and tags very nicely. The design for this feature evolved over time out of requests and suggestions from Subclipse users, along with a few niceties that I added while developing the feature when I realized I could use the information in additional ways. I was initially against adding the feature, as I generally try to stay true to the features of Subversion and do not like inventing concepts that are not really supported and backed by Subversion. However, in the end I really like the way this feature turned out, and I find it very useful in my own projects. There are some areas it could still be improved, but all in all, it is a nice feature.<br /><br />In no way would I attempt to make the claim that this answers every request/idea/complaint that Subversion users have had about the way tags are handled. That being said, it does address a lot of them :)<br /><br /><span style="font-weight: bold;">Overview</span><br />In many ways, the support for branching and tagging in Subversion represents a vast improvement over CVS. It certainly addresses many of the complaints with this feature in CVS. There is one significant drawback in the implementation in Subversion. Namely, the process of creating a branch/tag does not leave behind any "breadcrumbs" in the source of the branch/tag operation to indicate that the branch/tag was created. In other words, there is information in the branch/tag that indicates where it came from, but there is no similar information in the origin of the branch/tag that would let you see or know that the branch tag exists. The net result is that when looking at a file or folder there is no easy way to know which revisions belong to which tags.<br /><br />Subclipse provides a way for you to work around this problem by allowing you to maintain a Subversion property in your project that indicates the branches/tags that have been created from that project. The name of the property is <tt>subclipse:tags</tt>. The format of the property value is:<br /><div style="text-align: left;"><blockquote>revision_number,tag_name,relative_path,branch/tag</blockquote><br /></div><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhoncfKUWKgUi14OLK6GWG6ov_WLUDT8U1u3qXpsBmQUXhbPnHa_KQFdd5RcnW940rjRGgwz3qy6bLYLqWeWIx9X_UdGRFEVbzF4uRgt9R_e0zw6xkZtdd9QchnP5cALHIcO1wn8C3yg52j/s1600-h/property.png"><img style="cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhoncfKUWKgUi14OLK6GWG6ov_WLUDT8U1u3qXpsBmQUXhbPnHa_KQFdd5RcnW940rjRGgwz3qy6bLYLqWeWIx9X_UdGRFEVbzF4uRgt9R_e0zw6xkZtdd9QchnP5cALHIcO1wn8C3yg52j/s400/property.png" alt="" id="BLOGGER_PHOTO_ID_5021831533586640514" border="0" /></a><br /></div><br />The above screen shot shows what the property looks like if you were to edit it directly. However, Subclipse also provides a <b>Configure Branches/Tags</b> option on the Team menu that allows you to edit the property using a custom editor.<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwPZ6EbMlM4_ZFDRdGP5CFdEHLSfN0QBwAMUmgQQh_3n9x37cydbk7uoTEYM9PfGNLHtOWaKdvCpjs-xmqYNp0jxGkpy_ku3dw9JzWOBua9CrX-bu5TKdx_dYZVtfZcZtl4UPfVMEVxRDw/s1600-h/configure1.png"><img style="cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwPZ6EbMlM4_ZFDRdGP5CFdEHLSfN0QBwAMUmgQQh_3n9x37cydbk7uoTEYM9PfGNLHtOWaKdvCpjs-xmqYNp0jxGkpy_ku3dw9JzWOBua9CrX-bu5TKdx_dYZVtfZcZtl4UPfVMEVxRDw/s400/configure1.png" alt="" id="BLOGGER_PHOTO_ID_5021831336018144834" border="0" /></a><br /></div><br />Besides providing basic CRUD capabilities, the dialog also includes a built-in repository browser. This allows you to select one or more folders and add them as a branch/tag in one action. When folders are added in this manner, Subclipse automatically fills in the Revision number based on the Last Changed Revision of the selected folder.<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiIw5yOSYaa7GEh3qGKlbihcEJr5vp1VPs2VFj69RBP2lmhTciJD8g8HhtHgmI1XXeeLoMqfcqRBWKC8VbD5uCM3ZX9xdQAmYwb1OwYSIXMyVT5ljHR3kVkUhbkRS5UbCVDjJpm7oL8HojK/s1600-h/configure2.png"><img style="cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiIw5yOSYaa7GEh3qGKlbihcEJr5vp1VPs2VFj69RBP2lmhTciJD8g8HhtHgmI1XXeeLoMqfcqRBWKC8VbD5uCM3ZX9xdQAmYwb1OwYSIXMyVT5ljHR3kVkUhbkRS5UbCVDjJpm7oL8HojK/s400/configure2.png" alt="" id="BLOGGER_PHOTO_ID_5021831340313112162" border="0" /></a><br /></div><br />In addition to the <b>Configures Branches and Tags</b> option, there is also support for automatically updating the <tt>subclipse:tags</tt> property when you create a Branch/Tag using Subclipse. When you take this option, if we detect the <tt>subclipse:tags</tt> property on the item you selected, then we pop-up a dialog that lets you confirm that you want to add this new information to the <tt>subclipse:tags</tt> property. You then just have to commit that property change after creating the Branch/Tag. This feature does not exist when creating the Branch/Tag from the repository browser as it is only possible to modify a property value in a working copy.<br /><br />A nice aspect of using a Subversion property to drive this feature is that only a single user or build process needs to assume the responsibility of managing the property value. They just commit the property change and all users receive the benefits in their UI when they update.<br /><br /><span style="font-weight: bold;">Features</span><br />Once the property has been defined, there are a number of ways that Subclipse takes advantage of it to provider a better user experience in the UI.<br /><br /><b>History Browsing</b><br />This was really the number one reason for pursuing this feature in the first place. The History View has been enhanced to show the tags for a revision.<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjpm80nomCBhyphenhyphenEn54OuuojNkIYvtZe6GYZ2NgaTL3r6FCeP_V9C_jA-mS-9Z-twu_kbAyyKACrJNY6V5SlsMod5pVVZcEjGxj9DuoeNihlC6X72zmbj9Sz94JcokplQ5WcQ-aUty6zafIsM/s1600-h/history.png"><img style="cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjpm80nomCBhyphenhyphenEn54OuuojNkIYvtZe6GYZ2NgaTL3r6FCeP_V9C_jA-mS-9Z-twu_kbAyyKACrJNY6V5SlsMod5pVVZcEjGxj9DuoeNihlC6X72zmbj9Sz94JcokplQ5WcQ-aUty6zafIsM/s400/history.png" alt="" id="BLOGGER_PHOTO_ID_5021831340313112178" border="0" /></a><br /></div><br />When the History option is invoked against a local resource, we read the <tt>subclipse:tags</tt> property value from the local working copy and use its contents to populate the tags column in the view. A preference controls whether to show this information when browsing history directly from the repository. In this scenario, in order to show the tag information, we have to search the repository for the presence of the <tt>subclipse:tags</tt> property. On a slow connection you probably would not want to do this.<br /><br /><b>Compare Revisions</b><br />The Compare with Revision ... option has been enhanced to show tags in its history view. This makes it easy to know which revisions you want to compare.<p></p><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEilCKCrpMqv4FCIk1gucJ0tcmenKGAyBaTulZ80k78r0gbWPYwM_Y7c5mZ7GeDw5kye7o8zFu5NlUHdwm4nh0MxFu0d3wVP7pDqn9C3lNVhTXTyiC7ZohTdTaCLA5RQrHdSzCO71SIBZxkT/s1600-h/compare_revision.png"><img style="cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEilCKCrpMqv4FCIk1gucJ0tcmenKGAyBaTulZ80k78r0gbWPYwM_Y7c5mZ7GeDw5kye7o8zFu5NlUHdwm4nh0MxFu0d3wVP7pDqn9C3lNVhTXTyiC7ZohTdTaCLA5RQrHdSzCO71SIBZxkT/s400/compare_revision.png" alt="" id="BLOGGER_PHOTO_ID_5021831336018144850" border="0" /></a><br /></div><br /><b>URL Chooser</b><br />The URL Chooser that allows you to pick a URL in many of the Subclipse dialogs has been enhanced to show Branch/Tag information. This allows you to just select a branch/tag by it's name or identifier and the proper URL to that branch/tag will be automatically created. The enhancements we were able to make to this dialog turned out to be the best "side-effect" of adding this feature. Not having to type out, or browse to select, really deep URL's in the repository is a real time saver and usability improvement.<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQ8lPOt70poCkcYOty_PRXhY14JvUZCr_8325i3yfWL9jbP75A35l0e-I5wbJayFpg3hR5bmhjQ9uqfJ8taqXRRsnK7Zt3xW685yYyPwgU6C3f5MvdKPJmhGCcEJMDIptTzavNuOoWaUPL/s1600-h/rep_browser.png"><img style="cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQ8lPOt70poCkcYOty_PRXhY14JvUZCr_8325i3yfWL9jbP75A35l0e-I5wbJayFpg3hR5bmhjQ9uqfJ8taqXRRsnK7Zt3xW685yYyPwgU6C3f5MvdKPJmhGCcEJMDIptTzavNuOoWaUPL/s400/rep_browser.png" alt="" id="BLOGGER_PHOTO_ID_5021831537881607826" border="0" /></a><br /></div><br /><b>Compare with Branch/Tag</b><br />Technically this feature is not dependent on the property, but it was added at the same time and the property makes it easier to use. Subclipse provides a Compare with Branch/Tag option in the Eclipse Compare With menu. The option gives you the choice of producing a unified diff file or doing a graphical compare as shown in the screen shot below. The Eclipse graphical compare option can be fairly slow if you do not have a fast repository connection. Also, the Eclipse compare option will show differences in svn keywords which the unified diff option will not. That being said it is still convenient to have and combined with the enhanced URL Chooser, it is a very nice option.<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjutpsYNjvhFDSRnCJbmOmLG4fJ4nT0X-p84n8x1H1_hfPSwDEZrDHF7nULlKOjPceOstoGZ5Oyqx9SEKQSqcFKZ2SiEn-1uHRCS0rrNN0Mu25L4krAV61p_OFk1af7oea7HnVAbvbpXDSI/s1600-h/compare_branch.png"><img style="cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjutpsYNjvhFDSRnCJbmOmLG4fJ4nT0X-p84n8x1H1_hfPSwDEZrDHF7nULlKOjPceOstoGZ5Oyqx9SEKQSqcFKZ2SiEn-1uHRCS0rrNN0Mu25L4krAV61p_OFk1af7oea7HnVAbvbpXDSI/s400/compare_branch.png" alt="" id="BLOGGER_PHOTO_ID_5021831331723177522" border="0" /></a><br /></div><br />In the future, I would like to enhance the graphical compare option to either be driven by a unified diff file (which would be much faster and accurate) or perhaps a new routine that used the new svn diff --summarize option to produce the initial list of differences, instead of letting Eclipse calculate them. Either option would make it run a lot faster and eliminate the false positives caused by the use of keywords.<br /><br /><span style="font-weight: bold;">Future Enhancements</span><br /><a href="http://www.jroller.com/page/eu">Eugene Kuleshov</a> has requested some enhancements to this feature that might come in the future.<br /><br />The first is <a href="http://subclipse.tigris.org/issues/show_bug.cgi?id=471">issue 471</a>, which is to remove the revision number from the property value and instead just discover and cache it when needed in the UI. The reason he wants to do this is so that we can change the way we update the <tt>subclipse:tags</tt> property so that we do it before we create the branch/tag. Then the updated property information would be included in the new branch/tag. See this <a href="http://svn.haxx.se/subusers/archive-2006-03/0265.shtml">mailing list thread</a> for his reasons.<br /><br />I do have some concerns that this will unexpectedly slow down the UI when the cache is populated against a slow server. I suppose that could be solved with proper usage of a progress dialog, but I have the feeling this would happen so deep in the code that might be more difficult that it sounds. What I would ideally like to see is an ability to update the property in the branch/tag as part of creating it, but this would require new Subversion API support.<br /><br />Eugene's next request was <a href="http://subclipse.tigris.org/issues/show_bug.cgi?id=472">issue 472</a>. This request is to enhance the create branch/tag process to allow you to process several projects at once. I would really like to see Subclipse focus on this area once the 1.2.0 release is finalized. Basically, we need to make it easy to perform all of the branch/tag options on multiple projects. This would include, creating the branch/tag, but also switch, merge and probably compare. This is also entered in <a href="http://subclipse.tigris.org/issues/show_bug.cgi?id=596">issue 596</a>.<br /><br /><span style="font-weight: bold;">Conclusion</span><br />This is a nice feature that improves the user experience for Subversion users. There is always more to do, such as better multi-project support, but we will get there.<br /><br />The one negative I have found about this feature is that your branching policy will sometimes make it less effective. For example, the Subversion and Subclipse projects both have a policy where we create a branch, such as 1.2.x, to stabilize a release. All release tags are therefore made from the release branch, which means the <tt>subclipse:tags </tt>property, containing the tag information, lives on the release branch. However, developers mostly work in trunk and thus cannot really benefit from the History view feature of showing the tags in the view. This is an area where I think native Subversion support for knowing what tags a revision was copied to would be needed. If Subversion ever added this feature, it could likely tell that a file that was copied to a branch and then tagged is the same file that is on trunk. I guess the problem is whether Subversion can ever add a feature like this and still support the concept of "cheap copies" which is the foundation of the whole product.Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-2852931951046210811.post-25327291066825388842007-01-16T14:23:00.000-05:002007-01-30T14:02:32.594-05:00Features of the Subclipse Commit DialogThis is a post I have been wanting to write since I started my blog. In this post, I am going to cover some features that exist in the Commit dialog within Subclipse. It is very likely that you will not know at least about one of these features.<br /><br />Might as well start with a screen shot that shows the dialog and some of these features:<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1irp7LIHWmDfCRpKiglMKWYBtih_-Umu9jXJE8zZc-GvvRkLHkHevd1VuWhm_U5gfsux-Thmqr7uOQ_UxWsrap_iw5D04Z8-iwF4UH8AUXGHtfvnyfANZ_Tk9cQrP8KDD62kdT1jb3zr5/s1600-h/commit-dialog.png"><img style="cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1irp7LIHWmDfCRpKiglMKWYBtih_-Umu9jXJE8zZc-GvvRkLHkHevd1VuWhm_U5gfsux-Thmqr7uOQ_UxWsrap_iw5D04Z8-iwF4UH8AUXGHtfvnyfANZ_Tk9cQrP8KDD62kdT1jb3zr5/s400/commit-dialog.png" alt="" id="BLOGGER_PHOTO_ID_5020717290221039090" border="0" /></a><br /></div><br /><span style="font-weight: bold;">Integration with Issue Tracking Systems</span><br />I decided this topic was too big for this post, so I first wrote up a post on how to <a href="http://markphip.blogspot.com/2007/01/integrating-subversion-with-your-issue.html">Integrate Subversion with Your Issue Tracking System</a>. Refer to that post for the details.<br /><br /><span style="font-weight: bold;">Message Width Marker</span><br />Look closely at the right hand side of the commit message. See the feint line drawn through the edit control? That lets me see where a specified column of text resides so that I can format messages according to whatever guidelines might exist for the project I am working on. The Subversion commit message is just a blob of text that is stored the way you enter it, including (or not) any line feeds. A lot of people might have routines that parse or reuse the messages and often it is desired that the messages fit nicely within someone's terminal window.<br /><br />This feature first appeared in <a href="http://tortoisesvn.tigris.org/">TortoiseSVN</a>, and we added the same feature in Subclipse. To turn it on, you need to define an SVN property named "tsvn:logwidthmarker" with a numeric value that indicates the column where you want the line to appear, such as "79". Since most Eclipse users will be checking out Eclipse projects, you should only need to set this property on the project root folder. Otherwise, just set it on all folders. This rule applies to all of the subsequent features I will describe that involve SVN properties.<br /><br /><span style="font-weight: bold;">Handling Unversioned/Missing Files</span><br />The commit dialog will show any unversioned or missing files that appear beneath the folder you selected when you took the option. By default, unversioned files are not selected in the dialog, but you can change this in the Eclipse preferences under Team -> SVN. Missing files are never selected automatically. If you select these files, when you click OK, Subclipse will execute the svn add/delete command prior to running the svn commit command so that the items are properly included in the commit process.<br /><br /><span style="font-weight: bold;">Remember Previous Messages</span><br />There is a combo box in the middle of the dialog that shows previous commit messages you entered, including the text you entered before you hit the Cancel button. This can be useful if you write the commit message and then suddenly realize you left some debug code in that you want to remove before committing.<br /><br /><span style="font-weight: bold;">Message Templates</span><br />Subclipse supports two kinds of message templates. The first one comes from TortoiseSVN, and that is to set an SVN property named "tsvn:logtemplate" where the value of the property contains the template text. If this property is set, the dialog will come up with the text of the template already filled in. The second template system is an Eclipse feature first introduced by the CVS plug-in. This features lets you setup any number of templates in the Eclipse preferences. These templates are all then available in the drop-down combo that shows previous messages that were entered.<br /><br /><span style="font-weight: bold;">Require a Message</span><br />This feature also comes from TortoiseSVN. You can set an SVN property named "tsvn:logminsize" where the value is a number. When this property is set, the OK button will not be enabled on the commit dialog until the number of characters entered in the message is equal to or greater than the value of this property. So you can set this to a value like "10" and that would require the user to enter at least 10 characters. If for no other reason, entering a value of at least "1" can save a user from accidentally clicking OK without entering a message.<br /><br /><span style="font-weight: bold;">Internal Resizing</span><br />All of the sections of the dialog can be resized. So if you like a large area to enter comments, with just a couple of files showing, you can arrange the dialog that way. Likewise the opposite is true if you would prefer to be able to see more files.<br /><br /><span style="font-weight: bold;">Show Differences</span><br />This one is my favorite, and one that a lot of user's do not seem to know exists. You can double-click on any file in the list and see the differences in that file. This can really help in writing proper commit messages.<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjdwBe_qDb6t7HmFWi_ayqhLi9OdYgniQ9g9DaTCEUtDGJjC2JYuH3mNOjqy3brJU89Hk9RA6KW56myEvxGphperPTEdugLPX5t6C8nFHRPCFxRsA3gNRdiAplUB-2zzxVpM5wXgOdnq6aQ/s1600-h/commit-compare.png"><img style="cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjdwBe_qDb6t7HmFWi_ayqhLi9OdYgniQ9g9DaTCEUtDGJjC2JYuH3mNOjqy3brJU89Hk9RA6KW56myEvxGphperPTEdugLPX5t6C8nFHRPCFxRsA3gNRdiAplUB-2zzxVpM5wXgOdnq6aQ/s400/commit-compare.png" alt="" id="BLOGGER_PHOTO_ID_5020717092652543458" border="0" /></a><br /></div><br /><br />The only negative to this compare feature is that the dialogs are all modal so you cannot look at the compare while you are typing the commit message. I'd like to enhance the commit dialog someday so that the compare results showed in a new section of the dialog, but I am not sure if that would work well from a screen real estate point of view. There is also the question as to whether the Eclipse compare UI can be embedded in a dialog like that. I suspect it can.<br /><br /><span style="font-weight: bold;">Conclusion</span><br />The commit dialog in Subclipse contains a number of features that are designed to make the process of working with Subversion easier and more usable for you. Hopefully there were one or two features described in this post that interest you and that you did not already know about. Most of these features were first developed and included in TortoiseSVN, so I would like to just conclude this post with a thank you to the TortoiseSVN developers for paving the way. Thank you.Unknownnoreply@blogger.com9tag:blogger.com,1999:blog-2852931951046210811.post-47467642479154136532007-01-15T14:18:00.000-05:002007-02-01T15:20:18.173-05:00Integrating Subversion with your Issue Tracking SystemThis article will explore a technique for integrating <a href="http://subversion.tigris.org/">Subversion</a> development with your issue tracking system. This technique was cooperatively developed by the <a href="http://tortoisesvn.tigris.org/">TortoiseSVN</a> and <a href="http://subclipse.tigris.org/">Subclipse</a> development teams, and both products support the features that will be described.<br /><br /><span style="font-weight: bold;">Background </span><br />Many popular issue tracking systems have developed procedures for integrating with version control tools like CVS and Subversion. A common approach that is used is for the issue tracker to provide one or more Subversion hook scripts that interrogate the message provided in the commit process, looking for references to issues in the message text. Depending on the tool being used, there will often be some meta data stored within the issue tracker to record the files that were modified for that issue. Some tools support features that change the state of the issue, others might perform some kind of validation and possibly reject the commit transaction. This part is really up to the issue tracker and the hook script(s) they provide.<br /><br />The problem with this approach is that it only works as well as the ability of the issue tracker's hook script to correctly identify the references to issues in the commit message text. With no help being provided by the version control tool to help the user consistently format their message, this can be a difficult task to perform accurately. Also, even when everything works correctly, the integration is only in one place, the issue tracker. In other words, you can view an issue in the issue tracker and see what files were modified (or some other reference to the version control tool), but when looking at history in the version control tool, you do not have easy access to the related issues that were addressed by the commit.<br /><br />With all this in mind, these were the goals of the issue tracking specification that we developed:<ol><li>Provide a place in the UI of the commit dialog for the user to supply issue ID's. These issues are then inserted into the commit message in a consistent manner.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg3J_qODLe-M3F7H5gDkvlE3Bn3q25iTCLyxQBkv_vmAjDHAUh63GUVoaJgui0vBZGnmuup3uCDDfOLbFutqx01_cTf8-xf1D8XvsSKutOZuN_-qkrDW6KQhOdPxnrG8o8BhDqnQ9xNawQJ/s1600-h/commit-dialog.png"><img style="cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg3J_qODLe-M3F7H5gDkvlE3Bn3q25iTCLyxQBkv_vmAjDHAUh63GUVoaJgui0vBZGnmuup3uCDDfOLbFutqx01_cTf8-xf1D8XvsSKutOZuN_-qkrDW6KQhOdPxnrG8o8BhDqnQ9xNawQJ/s400/commit-dialog.png" alt="" id="BLOGGER_PHOTO_ID_5020328445356895650" border="0" /></a></li><br /><br /><li>Provide for the possibility of some simple validations in the UI. Such as verifying that the issue is a number, or warning if no issue is entered.<br /></li><br /><br /><li>When showing Subversion history in the UI, convert any references to issues in the commit message into clickable hyperlinks to the issue tracker.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0tBXG6oijnhKXwKurHr6NOBwCFynPpGlkLfRIzvt6v6C_zgvds3Us9Vx972CApecMDADD84lCThGmTw5QsZSHfQ8lls7Q6yGtQIbHx97cYKYq-yUWVNst3zDmb8sqX7wdTgTQnM_lg8h9/s1600-h/history-with-issue.png"><img style="cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0tBXG6oijnhKXwKurHr6NOBwCFynPpGlkLfRIzvt6v6C_zgvds3Us9Vx972CApecMDADD84lCThGmTw5QsZSHfQ8lls7Q6yGtQIbHx97cYKYq-yUWVNst3zDmb8sqX7wdTgTQnM_lg8h9/s400/history-with-issue.png" alt="" id="BLOGGER_PHOTO_ID_5020331748186746290" border="0" /></a></li></ol>You can view the full specification in the TortoiseSVN Subversion repository <a href="http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/doc/issuetrackers.txt">here</a>. (username = guest with no password)<br /><br />These features combine to give the user a better experience in terms of referencing their issue tracker from their Subversion client and also makes it much easier to write server side hook scripts that can accurately parse the commit messages. A nice aspect of this feature is that since the integration between Subversion and your issue tracker is still ultimately based on the text of the commit message, even users that are using a client that does not specifically support this feature can still participate in the integration by entering their commit messages in a format consistent with what this feature would have done for them.<br /><br /><span style="font-weight: bold;">Details</span><br />With all this in mind, how do you turn on this feature and/or configure it? The way that we settled on was to use Subversion properties to hold the configuration information. This allows one person to set it all up, and the configuration can then be pushed out to other users via the update and/or checkout process. In addition, the configuration just needs to be set on the top-level folder in the working copy. At runtime, the client will walk the working copy back to the root looking for the configuration. This means if you just set it on the root folder, that is enough. Keep in mind, that the client is walking the "working copy" not the "repository". If you have an environment where someone might conceivably check out at any folder level in the repository, then you might need to store this configuration as properties on every folder. Subclipse users are working in Eclipse, and Eclipse has a fairly rigid project structure. So for Eclipse users, it is pretty easy to configure as you just need to put the configuration on the project folder and you can be fairly confident that is what your users are checking out.<br /><br />Once that is decided, there are then several properties all prefixed with "bugtraq" which determines the configuration of the feature. We chose bugtraq with the slightly odd spelling just to avoid any potential current or future namespace conflicts. Here are the properties and an explanation of each, this is actually copied from the spec verbatim:<br /><br />NOTE: The specification has evolved a bit since it was first written and now breaks the feature down by a "basic" and "advanced" configuration where the latter is based on the use of regular expressions. Subclipse currently only supports the basic configuration options, and that is also all that this article covers.<br /><br /><span style="font-weight: bold;">Bugtraq Properties:</span><br /><br /><span style="font-style: italic;">name : bugtraq:url</span> <span style="font-style: italic;"><br />value : (string)</span><br />This value is the URL pointing to the bug tracking tool. The URL string should contain the substring "%BUGID%" which the client replaces with the issue number. That way the resulting URL will point directly to the correct issue.<br /><br />NOTE: The URL must be properly URI encoded by the user. This URL can be used by clients to create a link to the bug tracking tool when showing the log message of a revision.<br /><br /><span style="font-style: italic;">name : bugtraq:warnifnoissue</span><br /><span style="font-style: italic;">value : "true"/"yes" or "false"/"no"</span><br />If set to "true", then the clients will warn the user if the issue text box is left empty. But it must not block the commit, only give the user a chance to enter an issue number in case (s)he forgot it.<br /><br /><span style="font-style: italic;">name : bugtraq:label</span><br /><span style="font-style: italic;">value : (string)</span><br />This can be used by a client as a GUI label describing the text box where the user has to enter the issue number. If this is not set, then a default value should be used, e.g. "Bug-ID / Issue-Number :". Keep in mind though that most GUI clients don't resize their windows according to the size of GUI elements. So keep the size of the label string below 20-25 chars.<br /><br /><span style="font-style: italic;">name : bugtraq:message</span><br /><span style="font-style: italic;">value : (string)</span><br />If this property is set, then the client should show a text box in the commit window where the user can enter an issue number. The value string of this property is used by the client to create an additional line added to the log message. The string must contain the substring "%BUGID%"<br />which is replaced with the issue number the user entered before applied to the log message. The client will add the resulting string as a new line to the end of the log message the user entered:<br />logmessage + "\n" + resultstring<br /><br />In case bugtraq:append is set to "false", then the log message is defined as resultstring + "\n" + logmessage<br /><br />The client should make sure that the string doesn't have multiple lines. If more than one issue number is entered by the user (separated by commas), the client must make sure that there's no whitespace chars before and after the comma. And also the whole issue number string must be trimmed.<br /><br /><span style="font-style: italic;">name : bugtraq:number</span> <span style="font-style: italic;"><br />value : "true" or "false"</span><br />If this property is set to "false", then the client allows any character entered in the issue text box. Any other value or if the property is missing then only numbers are allowed as the issue number. One exception is the ',' char, which is used to separate multiple issues. The client must never complain if the text box is left empty, i.e. if no issue number is given. Not all commits are assigned to an issue!<br /><br /><span style="font-style: italic;">name : bugtraq:append</span><br /><span style="font-style: italic;">value : "true" or "false"</span><br />If set to "false", then the bugtraq:message part is inserted at the top of the log message, if "yes" or not set, then it's appended to the log message at the bottom.<br /><br />Since these are all Subversion properties, you need to use the svn propset command to set them on a folder within your working copy (there is no way to do it directly against the repository).<br /><span style="font-size:85%;"><span style="font-family:courier new;"></span><blockquote><span style="font-family:courier new;">svn propset bugtraq:append false .</span><br /><span style="font-family:courier new;">property 'bugtraq:append' set on '.'</span></blockquote><span style="font-family:courier new;"></span></span>You then need to commit those changes so that other users can get them. Keep in mind that in order to commit property changes to a folder, the revision of the folder in your working copy has to be the same as the HEAD revision of the folder in the repository.<br /><br />Here is an example of the properties set on one of the Subclipse projects as an example:<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirgde-UK-y5cjwGEYqxSBm3NXWPZ8OAV9bkAhSMFdy9xtaH9Oxi-ziA7eby5QQsAobDyMIXCKIhW2XOlD1nIP3hKOIfenQ_KILeaLbKOBx2gUFMs15bu3UPT0PEjY8FyMABozQKOeMerMk/s1600-h/bugtraq-props.png"><img style="cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirgde-UK-y5cjwGEYqxSBm3NXWPZ8OAV9bkAhSMFdy9xtaH9Oxi-ziA7eby5QQsAobDyMIXCKIhW2XOlD1nIP3hKOIfenQ_KILeaLbKOBx2gUFMs15bu3UPT0PEjY8FyMABozQKOeMerMk/s400/bugtraq-props.png" alt="" id="BLOGGER_PHOTO_ID_5020336700284038594" border="0" /></a><br /></div>If you refer to the previous screen shots, you can get an idea how these properties manifested in the UI of the commit dialog and the text that was inserted into the commit message.<br /><br /><span style="font-weight: bold;">Conclusion</span><br />This is a feature in Subclipse and TortoiseSVN that our users lobbied hard for and seem to love. I personally enjoy the easy access to issues that is created by the hyperlinks in commit messages when viewing history. Often reading the history contained within an issue is the best way to understand the context of why a particular change was made.<br /><br />I do not know the complete list of Subversion clients that have added support for these properties, but I know that it goes beyond Subclipse and TortoiseSVN and includes several of the web-based repository browsers.<br /><br />The Subclipse integration with <a href="http://www.eclipse.org/mylar/">Mylar</a> includes partial support for this feature as well. When browsing history within Subclipse, the Mylar "Open Corresponding Task" option will be present and will determine the issue based on these properties and the content of the commit message. I assume this would mean if you were using <a href="http://wiki.eclipse.org/index.php/Mylar_User_Guide#Bugzilla_Connector">Bugzilla</a> or another issue tracker with a rich editor in Mylar that the rich editor would be opened in place of the web browser. Unfortunately the <a href="http://wiki.eclipse.org/index.php/Mylar_User_Guide#Configuring_the_Synchronize_view_for_change_sets">Mylar Change Set integration in Subclipse</a> does not currently have a way to plug your issue number into the right part of the commit dialog. It does stick the URL of the issue in the commit message text, so all is not lost. Perhaps in the future it will be possible to enhance this so that the issue ID itself is populated.Unknownnoreply@blogger.com12tag:blogger.com,1999:blog-2852931951046210811.post-22769707343997158302007-01-13T20:03:00.000-05:002007-01-13T20:41:23.303-05:00Subversion 1.5: Tolerate obstructions during checkout/update/switchThis is my second article about new features in Subversion's trunk, features that will be included in Subversion 1.5. My previous article discussed enhancements in <a href="http://markphip.blogspot.com/2006/12/subversion-15-improvements-to-movecopy.html">Subversion's move/copy commands</a>. This article will discuss improvements that have been made to the checkout, update and switch commands -- specifically, the ability to tolerate obstructions.<br /><br />Prior to these changes, if Subversion needed to add a file or folder to your working copy as part of the checkout/update/switch commands, and a file or folder with the same name already existed, then the command would abort with an error. The message you receive will vary based on the command and the situation, but it will look something like this:<br /><blockquote style="font-family:courier new;"><span style="font-size:85%;">svn: Failed to add file 'foo.c': object of the same name already exists</span></blockquote>As of Subversion 1.5, you can add the --force switch to any of these commands to override this behavior and tell Subversion to tolerate the obstruction. The output you normally see from these commands will tell you when this happens. For example, it will look something like this:<br /><blockquote style="font-family:courier new;"><span style="font-size:85%;">E foo.c<br />A bar.c</span></blockquote>A new code of 'E' for 'E'xists has been added to inform you of this situation. What Subversion does in this situation is create the ".svn" meta data, as it normally would. The "pristine" copy of the file is stored based on the repository, as it always would be. The file itself, however, remains unchanged. If the file does not match the file in the repository, then svn status will show the file as containing local modifications. Those modifications can be viewed with svn diff, or committed with svn commit. Likewise, you can use svn revert to restore the local file to the pristine copy.<br /><br />These changes help with a number of scenarios that can happen in normal development. The original use case that we wanted to solve was a developer that downloaded a tarball of some product and winds up making some fixes. Since they started with a tarball, they do not have a Subversion working copy on their disk. If they want to commit their fixes, or even submit them as a patch, then they need to have a working copy. With this change, they could use the svn checkout command, and the --force switch, to checkout the code from the repository on top of their local copy. When the command completes, they will have a valid working copy. They can now create a patch with their changes, or commit them if they have access.<br /><br />With the code that is currently in trunk, in this scenario, the svn checkout command will still need to pull down the same number of bytes from the server as a "normal" checkout. It is possible that it could be enhanced in the future to more selectively pull down just the differences, something like an rsync. A change of that nature has been deferred for some future release or whenever someone comes along with enough motivation to tackle it.<br /><br />Here is another scenario where this change solves a problem. Suppose a developer has a project checked out. They create a patch to implement some feature or fix and that patch includes some new files. They submit the patch to the community and a developer reviews and commits it. When the original developer runs the update command, the command will fail unless they remembered to remove the new files they had submitted in their patch. Now, they can just use the --force option with the svn update command, and it will complete normally and just reconcile any issues. If the patch was committed exactly as it was submitted, the developers working copy should not show any modifications after the command completes. If the patch was tweaked, then a diff of the working copy would show whatever tweaks were made, and the svn revert command could be run to get the working copy back to a pristine state, ready for the next patch to be worked on.<br /><br />We will be making use of this new feature in several places in Subclipse, including several where we have had to code our own workarounds to get around this problem. There are also a couple of new checkout and project share scenarios where we should be able to utilize this new option to implement features that our users have asked for.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2852931951046210811.post-71706665860711006332007-01-07T14:22:00.000-05:002007-01-08T13:02:19.637-05:00Shelves in SubversionThere is a popular feature called "shelves" that was included in Microsoft's <a href="http://msdn.microsoft.com/vstudio/teamsystem/">Visual Studio Team System</a>. I am fairly certain that VSTS is not the first or only tool to have this feature and in this article I will show you how to get the same feature from Subversion. I think of shelves as essentially creating and using a branch to save some changes you have been working on, but now need to set aside, or shelve, for a while. Here is how Microsoft explains the feature in their <a href="http://msdn2.microsoft.com/en-us/library/ms181403%28VS.80%29.aspx">documentation</a>, which I found via a search:<br /><blockquote>Shelve your pending changes when you are not ready to or cannot check in a set of pending changes. There are primarily five shelve scenarios:<div id="sectionSection1" class="seeAlsoNoToggleSection"> <ul><li> <p> <b>Interrupt</b> When you have pending changes that are not ready for check in but you need to work on a different task, you can shelve your pending changes to set them aside.</p> </li><li> <p> <b>Integration</b> When you have pending changes that are not ready for check in but you need to share them with another team member, you can shelve your pending changes and ask your team member to unshelve them.</p> </li><li> <p> <b>Review</b> When you have pending changes that are ready for check-in and have to be code-reviewed, you can shelve your changes and inform the code reviewer of the shelveset.</p> </li><li> <p> <b>Backup</b> When you have work in progress that you want to back up, but are not ready to check in, you can shelve your changes to have them preserved on the Team Foundation server.</p> </li><li> <p> <b>Handoff</b> When you have work in progress that is to be completed by another team member, you can shelve your changes to make a handoff easier.</p> </li></ul> </div> </blockquote>The branching model in Subversion, with its use of "cheap copies" is well suited to provide similar capabilities and handle all five of these scenarios. In the rest of this article, I will detail two different ways to shelve changes using branches in Subversion.<br /><br /><span style="font-weight: bold;">Quick Method: Create Branch from Working Copy</span><br /><br />The first and easiest method is to simply create a branch from your working copy. A lot of Subversion users do not realize that you can do this. I actually use this technique a lot when creating complex tags. Just get your working copy exactly as you want the tag, and then create the tag based on your working copy.<br /><br /><span style="font-size:85%;"><span style="font-family:courier new;"><blockquote>svn copy . url://server/repos/project/tags/tagname -m "Create tagname"</blockquote></span></span>This creates the tag in the repository based on what is present in the working copy. Subversion does not even need to send any file contents to the repository to create the tag, so it still runs very fast.<br /><br />You can use this same concept to create a branch or shelf with the changes you are working on. Here is a screen shot from Subclipse showing how to do this:<br /><br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTQimh9AhyphenhyphenOB_4It0kZTEoJQdXrpquvnNYl8luiQz7O5iGPZ9xGEU0JI1dyl13PXL70SKu4TVV2Ulh4LB_EblIv7Pjdw6cHrN39v4-yjJ1xwPogdd9oFYoI9OpL8R_URBZ-AEgo2HUo0VS/s1600-h/shelve.png"><img style="cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTQimh9AhyphenhyphenOB_4It0kZTEoJQdXrpquvnNYl8luiQz7O5iGPZ9xGEU0JI1dyl13PXL70SKu4TVV2Ulh4LB_EblIv7Pjdw6cHrN39v4-yjJ1xwPogdd9oFYoI9OpL8R_URBZ-AEgo2HUo0VS/s400/shelve.png" alt="" id="BLOGGER_PHOTO_ID_5017676619129301074" border="0" /></a></div><br />Notice that the option to create the copy from the Working Copy has been selected. That is the key to this method. When the command runs, Subversion creates a copy in the repository based on the base revision of your working copy, however any local changes are also committed as updates. Likewise, if you have svn added or deleted any files/folders, then those are also included and it does this all in a single transaction.<br /><br />After the command completes, your working copy will still appear to be modified (because the changes were committed to a different branch then the one associated with the working copy). To get your working copy back to a pristine state, before beginning your next task, you will need to run the svn revert command to remove all local modifications. The svn revert command does not remove files and folders that were added, so you need to manually delete those after the revert.<br /><br /><span style="font-style: italic; font-weight: bold;">Hint:</span> <span style="font-style: italic;">The Subclipse revert process will remove selected unversioned files and folders. So if you run the revert option twice, the first time you run it, added files are made unversioned and the second time you run it, they are deleted.</span><br /><br />Creating a shelf using this technique is very easy. The problem with this technique comes when you want to work on your shelf again. To do so, you want to use the merge command to merge your changes from the shelf back into the current working copy which is associated with trunk or some other branch. The problem is that since the shelf was created in a single transaction, merging it is a little bit tricky. Suppose the shelve was created with revision 50. The normal way you might expect to merge it into your working copy would be to run a command like this:<br /><blockquote style="font-family:courier new;"><span style="font-size:85%;">svn merge -r49:50 url://server/repos/project1/branches/shelf</span></blockquote>This tells Subversion to merge the changes that happened with revision 50 into the current working copy. However, in this scenario, when you run this command you will get an error something like this:<br /><blockquote style="font-family:courier new;"><span style="font-size:85%;">svn: Unable to find repository location for</span><span style="font-size:85%;"> 'url://server/repos/project1/branches/shelf' in revision 49<br /></span></blockquote>The problem is that the shelf did not exist in revision 49, so the command errors out. The answer to this is that you have to run the merge using two URL's. The source URL would be the base location that your working copy was pointing to (which was the base of the copy) and the target URL would be the shelf. You also need to know what revision your working copy was at when you made the copy. You can determine this information by running the svn log command on the URL of the shelf. The output of the command will show both the URL and revision it was copied from. Unfortunately, this is also where it can get really complicated. There is a better than likely chance that your working copy contains mixed revisions (see my previous post on <a href="http://markphip.blogspot.com/2006/12/mixed-revision-working-copies.html">Mixed Revision Working Copies</a>). Assuming that is the case, when you made the copy from your working copy, you will have gotten a fairly complex transaction in the repository. As an example, this is the output I get from svn log using a fairly simple mixed revision example:<br /><span style="font-size:85%;"><blockquote><span style="font-family:courier new;">------------------------------------------------------------------------</span><br /><span style="font-family:courier new;">r9 | markphip | 2007-01-08 09:34:06 -0500 (Mon, 08 Jan 2007) | 1 line<br /></span> <span style="font-family:courier new;">Changed paths:</span><br /><span style="font-family:courier new;">A /branches/fromWC (from /trunk:3)<br /></span> <span style="font-family:courier new;">A /branches/fromWC/.classpath (from /trunk/.classpath:4)<br /></span> <span style="font-family:courier new;">A /branches/fromWC/.project (from /trunk/.project:4)<br /></span> <span style="font-family:courier new;">A /branches/fromWC/src (from /trunk/src:4)<br /></span> <span style="font-family:courier new;">A /branches/fromWC/src/org (from /trunk/src/org:5)<br /></span> <span style="font-family:courier new;">M /branches/fromWC/src/org/tigris/subversion/javahl/ChangePath.java<br /></span> <span style="font-family:courier new;">R /branches/fromWC/src/org/tigris/subversion/javahl/C</span><span style="font-family:courier new;">lientException.java<br />(fro</span><span style="font-family:courier new;">m /trunk/src/org/tigris/subversion/javahl/ClientException.java:7)<br /></span> <span style="font-family:courier new;">R /branches/fromWC/src/org/tigris/subversion/javahl/JNIError.java (from /trun</span><span style="font-family:courier new;">k/src/org/tigris/subversion/javahl/JNIError.java:8)<br /></span></blockquote></span><br />As you can see, I have files and folders copied from revisions 3, 4, 5, 7 and 8 and my shelf was created in revision 9. In this example, I know that revision 8 is the right value to use for the source of my copy, but in a more complex example, there may not be a right answer. Let's go back to our example, and just say that the shelf was created in revision 50 and it was created by copying trunk which was at revision 49. Assuming that is the case, then to merge the changes made in the shelf into your working copy, you would need to run a command like this:<br /><blockquote style="font-family:courier new;"><span style="font-size:85%;">svn merge url://server/repos/project1/trunk@49 url://server/repos/project1/branches/shelf@50</span></blockquote><br />This tells Subversion to construct a diff of the changes between trunk @ revision 49 and the shelf @ revision 50 and then apply that diff to the current working copy. When this command runs, your working copy will now contain all of the changes you shelved. You can then go back to working on your change and eventually commit it to trunk or whatever the appropriate branch is to receive the change. Here is a screen shot of the same merge command from Subclipse:<br /><br /><div style="text-align: center;"><span><span style="font-size:85%;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEsDyHjt_KUU7RVTrQgAlOHHI4OsLiRjw5bdVQmyjtKzlHH1OA_teR779-j21RMWqbbY8uYvHKGhjXs0sAWLIoIP3Jt9PlK7Qp2YfPly-HuSzomdMHJg-X2SuA5Rdl_sNuDj_RprCISz1c/s1600-h/mergeshelve.png"><img style="cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEsDyHjt_KUU7RVTrQgAlOHHI4OsLiRjw5bdVQmyjtKzlHH1OA_teR779-j21RMWqbbY8uYvHKGhjXs0sAWLIoIP3Jt9PlK7Qp2YfPly-HuSzomdMHJg-X2SuA5Rdl_sNuDj_RprCISz1c/s400/mergeshelve.png" alt="" id="BLOGGER_PHOTO_ID_5017688310030280802" border="0" /></a></span></span><br /></div><br />Note that you just have to un-check the box that says to "Use From: URL". This then allows you to enter different "From" and "To" URL's and revisions.<br /><br />To summarize this method, creating the shelf is easy, but using it again can be difficult. I will now show you what I think is a better, and much cleaner, method for creating shelves.<br /><br /><span style="font-weight: bold;">Better Method: Multiple Steps</span><br /><br />There are really two main goals with this method:<br /><ol><li>Remove the issue of mixed-revision working copies from the equation.</li><li>Isolate the changes you want to shelve from the process of creating the shelf so that they are easy to merge later when you want to use them again.<br /></li></ol>This is always the technique that I use and it is generally much cleaner than the first approach.<br /><br />The first thing to do is to create the shelf/branch. If you know your working copy is a little old, compared to the HEAD revision of your trunk or branch, then you can use the last revision you committed or updated to when creating the shelf. Otherwise, just use the HEAD revision:<br /><blockquote style="font-family:courier new;"><span style="font-size:85%;">svn copy -r HEAD url://server/repos/project1/trunk url://server/repos/project1/branches/shelf</span></blockquote>This command is creating the shelf directly in the repository, based on whatever URL and revision your working copy is associated with. In this example, I used trunk. The next step is to use the svn switch command to switch your working copy so that it is pointing at the shelf URL:<br /><blockquote style="font-family:courier new;"><span style="font-size:85%;">svn switch </span><span style="font-size:85%;">url://server/repos/project1/branches/shelf</span></blockquote><br />The switch command is also like an update. So if your working copy was not at the same revision you copied when you created the shelf, then it is possible that you will receive some updates, and perhaps even have some conflicts created in your working copy.<br /><br />Here is a screen shot from Subclipse of the Create Branch dialog. Note the check box on the bottom that lets you create the branch and switch your working copy to it one step:<br /><br /><div style="text-align: center;"><span style="font-size:85%;"><span style="font-size:100%;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiD4HglPC6x099m4hY_qnrdF67fuLOYaPZ7ApggM5md3rh94-btaEyueEWPrrAMRtmG0HpS9OMVeJg2extILEN9HFesGDpc5NrMsumC7VAujKo3ESk0yZ27qY1-4h83v7_PpGPguqotcckQ/s1600-h/shelveandswitch.png"><img style="cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiD4HglPC6x099m4hY_qnrdF67fuLOYaPZ7ApggM5md3rh94-btaEyueEWPrrAMRtmG0HpS9OMVeJg2extILEN9HFesGDpc5NrMsumC7VAujKo3ESk0yZ27qY1-4h83v7_PpGPguqotcckQ/s400/shelveandswitch.png" alt="" id="BLOGGER_PHOTO_ID_5017692394544179314" border="0" /></a></span></span><br /></div><br />Once you have dealt with any conflicts that might been created in your working copy from the switch, you just need to commit your changes to the shelf using the normal commit command. When you are done, just use the switch command to switch your working copy back to trunk or wherever you need to be for your next task. Unlike the previous method, you will not need to cleanup your working copy when you do this.<br /><br />At this point the shelf has been created and your changes have been committed in a way that will make it easy to merge them back later. The only part of this process that is potentially a bit more difficult than the first method is that you might have to resolve some conflicts before you can commit your changes to the shelf, and depending on why you are creating the shelf, you might not have the time to do this. If you create the shelf branch from the revision you have loaded in your working copy, you should minimize any potential for conflicts.<br /><br />When you need to work on your shelved code again, it is easy. Just use the merge command to merge the changes from your shelf to your current working copy. Suppose you created the shelf with revision 44, spent some time resolving conflicts that were created when you switched, and then commited the changes to the shelf with revision 50. To merge the changes in the shelf to your current working copy, just run this command:<br /><span style="font-size:85%;"><blockquote>svn merge -r49:50 url://server/repos/project1/branches/shelf</blockquote></span><br />This tells Subversion to merge the changes made in revision 50 to your current working copy (I could have used any value between 44 and 49 for the from revision). Since we separated the process of creating the shelf, from the changes you wanted to store in the shelf, this is an easy command to run. When the command completes your changes will have been merged into your working copy for you to pick up the work where you left off. When you are done, you just commit everything to trunk, or whatever branch is associated with your working copy, and you are done. The branch you created for the shelf can now be deleted from the repository if desired.<br /><br /><span style="font-weight: bold;">Summary</span><br />I went into a lot of detail in this article but hopefully you now know a lot more about how branching and merging work in Subversion. You can apply this information in your daily work process and use Subversion as a tool that helps you do your work better and more efficiently. I wrote this article under the pretense of the Shelving concept, but it is really just basic branching and merging in the end. I think one of the strengths of the Subversion design is that they kept it all very simple and you just use the basic functionality to build the process you want.Unknownnoreply@blogger.com9tag:blogger.com,1999:blog-2852931951046210811.post-57279777101489328152007-01-05T08:53:00.000-05:002007-01-05T08:59:34.583-05:00Combating Sudden Slowdowns in Subversion<a href="http://www.subversionary.org/">Martin Tomes</a> writes about a <a href="http://www.subversionary.org/martintomes/mcafee-and-subversion">20x performance slow-down</a> in checkouts after installing a new anti-virus program. There have been a lot of reports over the years of various anti-virus programs causing slow-down's or other problems with Subversion on Windows. It is a good thing to check if suddenly you are having performance problems or other errors. Hopefully you are at least using a program that lets you fine-tune what and how it is doing the checking.<br /><br />Another item that people have reported to cause slow-down's is the XP drive indexing. This can be disabled by right-clicking on the drive and choosing Properties. There is an option at the bottom of the General tab that controls whether Indexing is allowed. I do not know if other tools that index your drive, such as the Google Desktop can cause similar problems, but I suspect they can.Unknownnoreply@blogger.com1