Subscribe: Brian Kotek: Inversion of Control - Change Management
Added By: Feedage Forager Feedage Grade B rated
Language: English
back  code  eclipse  files  locally  management  mylyn  repository  set  subversion trac  subversion  svn locally  svn  task  trac 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Brian Kotek: Inversion of Control - Change Management

Brian Kotek: Inversion of Control - Change Management

Brian Kotek on ExtJS, DeftJS, CoffeeScript, Java, Groovy, Grails, Design Patterns, and Object-Oriented Programming

Published: Thu, 18 Jan 2018 11:53:00 -0700

Last Build Date: Tue, 22 Apr 2008 08:52:00 -0700


Want Free Subversion, Trac, Mylyn, and More? Of course you do.

Tue, 22 Apr 2008 08:52:00 -0700

If the idea of 500 Mb of free Subversion, Trac (with XML-RPC access for things like Mylyn), Wiki, and a whole lot more sounds like a good thing to you, check out I signed up last night and am really quite floored.

This thing has virtually everything one could want in a project management, source code, ticket tracking, and team collaboration setup. And again, it's free for up to 500 Mb of stuff. And after that it is a paltry $12.50 per month for 5 Gb of storage, plus a few extras like https access.

I've been hosting my own SVN locally but have increasingly been thinking about moving it to an external service so that I can get to it from anywhere. This seals the deal. So far, Assembla has been very impressive, and if it keeps up, I'll be springing for the $12 commercial account and be done with it.

Have a look if you have been thinking about jumping on the Subversion or Trac bandwagon but don't have the time or inclination to set up your own server. And if anyone else has been using Assembla, please share! Thanks.

For Users of Eclipse, SVN, and Trac: Mylyn Utterly Rocks

Thu, 20 Mar 2008 09:05:00 -0700

I've been using Eclipse as my IDE for a while now. It's just far too sweet to have my CF IDE and Flex IDE together, plus XML, CSS, HTML, ANT, and all the rest. I've also been a Subversion zealot for a long time. Quite frankly, if you're not using Subversion, for everything related to your development, then you're nuts. And a glutton for punishment. This means all of your code (yes, even those stupid little tests where you try something out), but also all of your documents, database schemas, SQL queries, ANT build files, etc.

But this entry isn't a plea to your logical side to use Eclipse or SVN. I'm assuming you already are. No, this entry is about integrating Trac task management into Eclipse through the Mylyn plugin.

Put simply, Mylyn kicks ass. It links to your Trac repository via web interface or, better, XML-RPC. If you don't have Trac, consider using a service like CVSDude which includes SVN and Trac, or setting up a fully configured virtual server using Jumpbox.

Once you get things set up, Mylyn allows you to handle all aspects of task management from right inside Eclipse. It ends up looking like this:


As you can see, it gives you a full list of Trac tasks. You can sort or categorize these any way you want to. It lets you do a "focus on the workweek" mode, which limits what you see to only tasks due this week. You can create, modify, or close tasks right from Mylyn, no need to work with the crappy Trac web interface. This alone is really great, but it gets better.

Mylyn lets you attach a "context" to any task. This means it will keep track of what files you are working on that relate to the current task. So if you come back to a task later and activate it, Eclipse loads the attached context and shows only the files and resources that have to do with that task! This is great since it makes it much easier to work on a task without seeing a bunch of unrelated files. Of course you can choose to show everything in your workspace again if you need to add more files to the context. This is really a great idea.

Finally, if you have the proper connection set up between Subversion and Trac (which CVSDude and Jumpbox do), you can close Trac tickets directly in your commit comments! So if you commit with a comment like "Fixes #188", ticket 188 will automatically close and have a comment added that references the Subversion revision that closed it!

All of this really creates a full-circle version control and task management capability, all from within the IDE. More details are available at the Mylyn page, or you can read a more thorough article at IBM. I'd urge anyone to have a look at this very cool plugin and enjoy the immediate workflow benefits. And to anyone already using Mylyn, feel free to share your experience or any tips you have.

Overview of Using Subversion Locally

Wed, 03 Jan 2007 11:50:00 -0700

I was browsing through the recent CF-Talk threads and came upon a long one regarding source control. Naturally, Subversion was mentioned. There seemed to be a lot of back and forth, with some people not appearing to understand what/why you'd want to use Subversion. I thought I'd post my thoughts on Subversion, and also go over how I use it locally. First, the underlying mechanics of Subversion (SVN) are very simple: SVN holds a version history of all files in a repository. You "get" the latest files by getting the latest versions from SVN. You make changes to a file locally. You "push" your changes back to the SVN repository. Normally this goes through with no problem. Occasionally it will fail with an error because someone else edited the same file. In that case you can pull down the latest and... If you and the other user did not both edit the same line of code, SVN will simply merge your changes together. If you and the other user did edit the same line of code, you will be given a difference screen and asked to reconcile the changes. Once the files are merged or reconciled, you push them back to SVN Now everyone else using the repository has access to the latest code. That's really all there is to it. It's not very complicated. 98% of the time you just pull down and push up your changes and everything is peachy. Sometimes you do have to reconcile changes to a file but it is pretty rare that two developers modify the same line(s) of code at the same time. If this happens a lot, it probably indicates the need for better coordination of what people are working on. For reference, there is a whole book on the details of using SVN available online for free. It's slightly outdated but the vast majority of the ideas still apply. For team development something like this is absolutely mandatory. Otherwise, attempting to integrate what everyone is working on into one codebase would be a nightmare. However, I also use SVN locally for keeping histories for word documents, test code, presentations, and just about anything else that I think has any importance. Being able to revert to previous versions when (WHEN) I make a mistake is a major relief. It's up there with having data backups for your system when your hard drive starts grinding. If you want to try using SVN locally, its quite easy! Setting up SVN manually is actually kind of a pain. Luckily (at least if you're running Windows), you don't have to. There is a wonderful One Click Installer that sets up SVN locally and also installs the great Explorer extension TortoiseSVN which lets you perform SVN tasks right from Windows Explorer. (P.S. If there are similar setup packages for Mac or Linux please comment and let me know. Thx.) OK, now one of the issues with SVN is that each repository is a complete entity. This means if you try to set up one giant uber-repository for everything on your system, you'll probably regret it. This is because versions in SVN apply to the entire repository. As you might imagine, this means you could change a file at revision 10, then go on changing other files for weeks to revision 20. Then, if you wanted to revert to revision 10, you will roll back all the other changes too.(I'm not fully explaining this, you CAN get individual versions of individual files, but if you need to roll back the whole repo this can be an issue). This would be annoying, and luckily it is also unnecessary. You can set up multiple repositories for different things. I created a directory called svnrepos, and I set up my individual repositories within it: OK, with repositories set up, the next question is how to connect to them. There are two ways to connect, one it to use file paths and one is to use the SVN network connector. I recommend using the SVN approach when possible. The One Click Setup program will install the necessary SVN Server service in Windows which should cover you. You can add files to the repository by clicking on any directory, choosing "import" from the TortoiseSVN context m[...]