Subversion – Williamo's Blog

Git: Complex Simplicity.

I may be totally off on some/all of these points here, but I thought I’d share some tidbits I’ve learned during my deep-dive of Git research tonight:

Git is deceptively simple.

Coming from a background in Subversion, I expected to have to jump through a bunch of hoops to get a repository configured, then get a server configured, etc. It took me most of the night to realize that you really don’t need anything other than the git binaries and a place to put your repository (local or remote).

If you do want to use a remote server to coordinate your repository, try just creating a bare repository on a remote server you can access via SSH, and “git clone” from there. Check out this Stack Overflow post for a great example: http://stackoverflow.com/questions/4948190/git-repository-sync-between-computers-when-moving-around

If you’re coming from Subversion, start by abandoning the concept of a partial checkout.

This concept kept me from making progress with Git longer than any other misconception I had. If you get caught up in trying to recreate your Subversion workflow in Git, you’ll get frustrated. If you embrace the concept of lots of small repositories that represent the folders/projects that you’d selectively check out from a master repository, then you’ll get Git right away. (FWIW, I did read about git submodules, but for my own purposes, fully separate repositories work best.)

The best way to learn is to experiment!

The best advice I can give is to just get your feet wet. Once you have a local version of Git installed, just start creating repositories and experiment with clones, commits, pushes, and pulls. If you do plan to work with a team and/or a remote repository, I highly suggest signing up for a GitHub account – it’s free for public repositories and pretty cheap ($7/mo starting) for private repositories.

There’s tons of help out there…

Speaking of GitHub, they also have a great site to help you get started using both Git and GitHub: http://help.github.com/

Besides the guide on GitHub, here are some of the best guides I’ve found yet:

Pro Git – Great free book on Git usage and configuration.
GitSvnCrashCourse – Git concepts for Subversion users.
Git on Wikibooks
Git User’s Manual: Git Quick Reference – A tl;dr for the rest of the manual.

svn – How to solve merge issues in large Subversion repository? – Stack Overflow

After spending the night playing with Git and trying to wrap my head around the best way to migrate our large Subversion repository to Git (or Mercurial), I realized that I was really trying to solve a core issue with our Subversion merge workflow at the office and that it might help to post the issue on Stack Overflow for more input from the community.

So, here’s the question I posted to Stack Overflow, along with a link to the post there:

How to solve merge issues in large Subversion repository?

Before I explain the core issue, let me say that I’m actually quite interested in migrating our source control from Subversion to Git/Mercurial if it really is a better solution for our issues, but I’m really looking for the best solution without causing a lot of unnecessary stress on the team. (In other words, I’m not looking for the “dump Subversion altogether and move to Git” answer, since that involves a lot of thrashing and a steep learning curve.)

Now that’s out of the way, here’s our core issue:

My development team is working with a relatively large Subversion repository, where all development used to be done directly on the Trunk. A request from above for a faster release cycle led us to split our work into separate branches, with each branch containing a mirror of Trunk at the time the branch was created and sub-teams working in parallel on each branch. The new cycle is to release a specific branch to production, then merge the new changes into trunk, and merge trunk changes into each of the other branches.

Unfortunately, this has become a very painful and error-prone process, and we need to find a better way to perform our merges that also takes into account simple changes between branches such as code reformatting (some of us use “cleanup code” on our source files, some don’t).

To summarize, we need help figuring out a better way to merge that doesn’t require one or more of our developers to spend an entire day manually resolving conflicts.

(Sorry if that’s a little vague or rambling; I’ll be happy to clarify or provide more details upon request.)

Thanks in advance for any help you can provide!

the hamstu » The Typography of Code

Cool post with a lot of great history and font samples!

As a self proclaimed programmer/designer I enjoy not only the logical and practical things in life, but also the beautiful and well designed. And I find the greatest pleasure when these things converge to produce something extraordinary.One such thing is Typography. Typography is the art of language, the visualization of the spoken word. A medium by which non-verbal communication is made possible. And though I profess no expertise in this art, I have come to deeply appreciate it’s power and ability to convey the same message in so many different ways. Each with a unique feeling and style.

The Messenger

In 1956 Howard Kettler designed the typeface Courier. It was made for IBM’s new (and revolutionary) line of electric typewriters. Originally called “Messenger”, Courier is one of the earliest fixed-pitch (also known as Monospace) fonts, meaning each character takes up the same amount of space on a line; allowing for easy tabular alignment and legibility.

Courier was a hit, and as many made the transition from typewriter to computer, this classic typeface wasn’t far behind. It was included in all early Apple computers, and while creating the core fonts for Windows 3.1, Microsoft hired Monotype Typography to give Courier a makeover. And so Courier New was born, as a thinner and cleaner version of it’s former self.

via the hamstu » The Typography of Code.

Subversion: This client is too old to work with working copy ‘XXX’

I thought I’d thoroughly read this article, but upon reading it again today, I noticed a key point I’d missed. If you can’t upgrade your SVN client, do a fresh checkout with the older client. I’m going to have to try this now…

This client is too old to work with working copy ‘XXX’

The full error message is:
This client is too old to work with working copy ‘.’; please get a newer Subversion client.

You will get this error message once you have used a Subversion client linked with a higher Subversion version, and then try to execute a command with a Subversion client linked with an older version, e.g., you used an 1.4.x client on your working copy, and now you try an svn 1.3.x client on the same working copy.

The reason for this is that Subversion 1.4 and 1.5 upgrade the working copies transparently on every command. But once the working copy format is upgraded, older clients can’t access the working copy anymore because they don’t know the new format.

The only solution to ‘fix’ this is to upgrade whatever clien

via This client is too old to work with working copy ‘XXX’ | TortoiseSVN

Ridiculous Subversion Behavior

Yesterday, I attempted to move some of our content from a local filestore into our main subversion repository. I copied the files to my computer, all 22472.67 megabytes of it, and used TortoiseSVN to import the data to our repository.

Being that it was over 22GB of data, I expected it to take a very long time, and it did, 310 minutes and 3 seconds (approx. 5.2 hours). What I didn’t expect was that TortoiseSVN neglected to check for commit/import requirements *before* the import process and waited 5.2 hours, after all the data had been transferred, to tell me:

Error: WHOOPS! Insufficient Log Message. Must be greater than 10 characters.

Wow. Whoops, I just wasted 5 hours of my computing time and network bandwidth to import 22GB of data that was immediately reverted *after* the whole process should have been completed.

Don’t get me wrong, I love Subversion to death, and TortoiseSVN is an awesome client. This behavior, though, seems pretty ridiculous to me.

What do you think?

Assembla: Free hosted SVN and more…

I’ve spent quite some time looking for a hosted Subversion repository that had a cheap or free trial option so that I could migrate my locally hosted repository (seems silly to host your repository on your own machine, doesn’t it?) to somewhere online.

Guess I wasn’t looking well enough, because today I (finally) stumbled upon a solution which meets all of my needs and more, Assembla.

If you’re looking for a place to host your development projects, I’d highly suggest Assembla, even if only for the *free* hosted Subversion repository which can be made private or public, unlike other free services which only offer public open-source hosting. Not that I’m knocking Sourceforge or Google Code, it’s just that I’m working on a consulting project that can’t be left out in the open (as I’m sure is the case with many of you out there as well).

Here’s a list of their plans (current as of this posting):

…and since you probably can’t read that without clicking on the expanded image, here’s the link to their pricing plans: http://www.assembla.com/tour

The array of development tools they have to offer is quite impressive, and I’m seriously considering upgrading to the Commercial plan ($12.50/month) to get more space.

For what it’s worth, Box.net, if you’re listening – you should really consider offering (real) WebDAV support and/or Subversion through your API, because *that* would make your site the killer app I’ve been waiting/paying for.

Also, here’s another great post with information about Assembla:
http://coding-time.blogspot.com/2008/04/free-subversion-wiki-at-assemblacom.html

…and they also have a great post about Subversion and how it works:
http://coding-time.blogspot.com/2008/04/subversion-visually-explained-in-30sec.html

Hack Attack: How to set up a personal home Subversion server

Great article from LifeHacker (and very useful, as I’m just about to set one up myself) about how to set up your own Subversion server:

Subversion is open source version control software used primarily by developers that keeps every revision of important, frequently changing files. However, Subversion can be useful for many different purposes, whether you’re a web developer or a novelist – especially if you like to work in plain text.

Think of Subversion as a wiki-like repository for your files. Each time you make a change to a file or group of files that you’re happy with, you can commit those changes to your Subversion repository. If you don’t like where the changes got you, Subversion can compare your current version with any previously-committed version and pick out the best of the best so you never have to worry about finding your way back to a good or working version of a file.

In this first of my two-part Subversion series, I’ll show you how to set up and run your own Subversion server. Next week, we’ll get into the nitty gritty of using Subversion.

(via Hack Attack: How to set up a personal home Subversion server)