DaedTech

Stories about Software

Mar
13

By

SVN Global Ignore

Category: Lessons Learned Tags: |

This morning, I was adding a playpen I’d created of an enormous project to subversion. In my playpen, I was only editing a handful of .cs files, but I wanted to add all .cs files to my little repository. What I didn’t want to add were, obviously, outputs of the project, but other stuff that is sourced controlled in that project, like various media files and other space-suckers.

My first thought was to impose ignores on the individual directories, manually adding things to the ignore list, but that’s incredibly cumbersome in a project of this size. At this point, I remembered the SVN global ignore settings where I can have the shell simply omit stuff in my add window and show it as ignored in explorer windows (MS Windows, here, obviously).

To access it, rick click anywhere and go to TortoiseSVN->Settings. You’ll see the following, and circled is what you want to edit:

You can put extensions here with wildcards and you can, as I did, put the names of directories in here (such as bin, debug, release, etc). Once you put these in, they will be ignored by default and they will not appear in the “add” window of tortoise. You can still add them — this does not supersede actual source control. You just have to do it manually.

May
20

By

VisualSVN

Category: Lessons Learned Tags: , |

Back Story

Recently, I set up a media wiki installation. The surrounding requirements were such that I was forced to use a Windows 2003 server instead of Linux, which would have been my preference, but hey, when life gives you lemons, turn the lemon into a WAMP stack. And that’s just what I did. The installs for Apache, PHP, and MySQL went quite smoothly in spite of having to use Windows, and I was up and running with Mediawiki in no time. As an aside, I should note that I tried out a handful of “all in one” WAMP stack offerings and none of them really seemed to work very well. Doing it by hand actually turned out to suit my needs best.

I should also point out that I don’t really have anything against Windows OS at all–I just prefer Linux when it comes to servers. Less overhead, easier security, and more bang for your RAM/processor buck. And I also prefer not to have constraints imposed on me, but c’est la vie.

So with my new Mediawiki install in place on the WAMP stack, I was thinking about backup schemes. I downloaded and installed MySQL Administrator GUI tool (now EOL’ed in favor of MySQL Workbench, which I think needs to get a little more mature and iron out some kinks) and configured an automated weekly backup of the Mediawiki database. Of course, that’s only half the story with Mediawiki–you also need to back up changes you’ve made to the PHP files themselves, where applicable, and any files and images uploaded to the wiki.

My Old Friend, Subversion

For this backup, I decided to go with subversion, reasoning that Tortoise would make it easy for me to see when I had modified files or when people had uploaded things to the wiki. I’d commit periodically, perhaps in conjunction with my automated DB backups, and this would give me a way to completely recreate my Mediawiki install at any point. If I hosted a subversion server on my server machine, I could commit weekly to it locally, and then update from another machine to ensure that I had an offline copy at all times. Perhaps not the most sophisticated backup scheme in the world, but it would get the job done, and I’d have a subversion server as a bonus.

With a New Twist

So when I went to download a subversion install for my Windows server, I stumbled on VisualSVN. Curious, I read about it a bit and decided to give it a whirl. I downloaded the MSI and installed it locally. I could not have been more pleased with the results. I use a subversion server at home on a Fedora server, and when I set that up, I had to mess around with configuring Apache and do something or another with security certificates, if I recall correctly. It’s been a few years, but I remember it being something of a hassle.

VisualSVN ran me through a wizard, and I was up and running with a password protected, directory-level-configurable subversion server that used secure HTTP. It was literally that simple. Already pleased, I saw that there were two main modes of security–subversion and Active Directory. Subversion was default, and it required me to create users and assign them passwords.

At first, this is what I went with, but I was a little put off to learn that the users wouldn’t be able to change the initial passwords that I assigned them. I was, however, pleased to find that I could control with the finest granularity which users had access to which directories. So I set off in search of a scheme that would allow users to change their own passwords. I switched to the Active Directory setting and started to play with it. What I discovered was that it was a snap to setup users needing to login with their own Windows Domain credentials.

So, viola! I didn’t need to create accounts or assign passwords and ask users to change them. They were already synced up with their own logins. From here, I was able to keep the same granularity by adding users in from the domain rather than manually. As setups went, I had a pretty slick one in about fifteen minutes for subversion.

The only drawback, as I see it, is that users can cache their domain passwords locally so as not to have to supply credentials for every SVN operation that they do. The drawback isn’t that they aren’t queried each time, which would be annoying, but rather that they can store their passwords. Of course, the passwords are encrypted by virtue of the HTTPS protocol, so this is really a small nitpick, and I really see no good way around it short of annoying the repository’s users. Not to mention, other applications like MS Outlook and web browsers offer the same kind of local storage, so it isn’t as if I’m doing something unprecedented.

So, if you get a chance, I highly recommend checking out this tool. The version I installed is a free one, though there is a fairly reasonable enterprise edition that gets you some more bells and whistles (if I recall correctly, it uses your current login credentials instead of a user/pass challenge). I might go to that later if the SVN install gains some traction and users like it.

Jan
19

By

Version Control Beyond Code

Category: Lessons Learned Tags: |

One of my favorite OSS tools is Subversion. I’ve used it a great deal professionally for managing source code, and it’s also the tool of choice for my academic collaborations between students not located on campus (which describes me, since my MS program is an online one). It seems a natural progression from CVS, and I haven’t really tried out GIT yet, so I can’t comment as to whether or not I prefer that mode of development.

However, I have, over the last few years, taken to making use of subversion for keeping track of my documents and other personal computing items at home, and I strongly advocate this practice for anyone who doesn’t mind the setup overhead and sense of slight overkill. Before I describe the subversion setup, I’ll describe my situation at home. I have several computers that I use for various activities.  These computers include a personal desktop, a personal netbook, sometimes a company laptop, and a handful of playpen machines running various distros of Linux. I also have a computer that I’ve long since converted into a home server — an old P3 with 384 megs of RAM running Fedora. Not surprisingly, this functions as the subversion server.

One of the annoyances of my pre-personal-subversion life was keeping files in sync. I saw no reason that I shouldn’t be able to start writing a document on my desktop and finish it on my laptop (and that conundrum applies to anyone with more than one PC, rather than being specific to a computer-hoarding techie like me). This was mitigated to some degree by setting up a server with common access, but it was still sort of clunky.

So, I decided to make use of subversion for keeping track of things. Here is a list of advantages that I perceive to this approach:

  • Concurrent edits are not really an issue
  • Creates a de facto backup scheme, since subversion stores the files in its repository and requires them to exist on at least one additional machine for editing
  • Combined with tortoise client for windows, allows you to see which folders/files have been edited since you ‘saved’ changes to the repository Modified subversion folder
  • You can delete local copies of the files and then get them back again by running an update — handy for when you want to work on collaborated stuff but not take up local space. This beats the central storage model, particularly with a laptop, because you can work on a file not on your home network without missing a beat
  • You have a built-in history of your files and can revert to any previous version you like at any time. This is useful for backing up something like Quicken data files that continuously change. Rather than creating hundreds of duplicate files to log your progress over time, you just worry about one and let subversion handle the history.
  • You can easily create permissions as to who has access to what without worrying about administering windows DNS, workgroups, fileshares, and other assorted IT minutiae.
  • Whether you were originally or not, this gives you bonafide experience as an SVN administrator

On the other hand, there are some disadvantages, though I don’t consider them significant:

  • Requires riding the SVN admin learning curve.
  • Requires a server for the task (practically anyway — you can always turn a PC into a SVN server with the file based mode, but I’m not a huge fan)
  • Can be overkill if you don’t have a lot of files and/or sharing going on

So, I would say that the disadvantages apply chiefly to those unfamiliar with SVN or without a real need for this kind of scheme. Once it’s actually in place, I’m hard pressed to think of a downside, and I think you’ll come to find it indispensable.

To set this up, you really only need a server machine and TortoiseSVN (windows) or a subversion client for Linux. I won’t go into the details of server setup with this post, but suffice it to say that you set up the server, install the clients, and you can be off and running. If there is some desire expressed in comments or I get around to it, I can put up another post with a walkthrough of how to set up the server and/or the clients. Mine runs over the HTTP protocol, and I find this to be relatively robust compared to the file protocol and non-overkill compared to the secure protocol involving keys. (Since this is a local install and my wireless network is encrypted with WPA-PSK, I’m not really worried about anyone sniffing the transfers.)