Source control

Subversion.

Subversion. By far.

Try it out at OpenSVN.

I'm personally fond of subversion with TortoiseSVN.

I use subversion in conjuction with TortoiseSVN on Windows for my own projects. It's a very good system.

Quote:

Original post by SiCrane I'm personally fond of subversion with TortoiseSVN.

+1. TortoiseSVN is quite polished.

Man, I'm surprised that more people haven't switched to distributed SCMs. I'm a Git user myself.

Quote:

Original post by pinacolada Man, I'm surprised that more people haven't switched to distributed SCMs.

It's unnecessary if your development is single-developer or occurs only at a single site.

I'm evaluating SCMs for a project a work, though, so thanks for the reminder to consider Git. (We currently use SourceSafe.)

Another vote here for Subversion + TortoiseSVN. We use these tools at work and they have work very well for us, even our remote users.

We also use Trac for basic project management (e.g., defects, tasks, milestones, etc). Though not perfect (no multi project support) it has some excellent features such as the ability to integrate with a subversion repository. This allows me to commit changes in my source (e.g, a bug fix) and relate that to the ticket in Trac that describes the bug. So I can , in Trac, see the precise changes that resulted in the resolution of that ticket.

I find the combination of Subversion, TortoiseSVN and Trac to be an excellent solution.

Quote:

Original post by Oluseyi It's unnecessary if your development is single-developer or occurs only at a single site.

I think DSCMs still have a few advantages in those situations.

One is, instant local branches. Even on single-developer projects, it's nice to be able to make experimental local branches, so that you can make crazy changes without breaking the main version. You can continue to support the main version (bug fixes, etc), while the experimental branch is in progress. Then you can decide to toss the branch or merge it back in.

Quote:

I'm evaluating SCMs for a project a work, though, so thanks for the reminder to consider Git. (We currently use SourceSafe.)

Oh man, good reason to upgrade.

As a side note, I don't know if I would recommend Git for company use. It's still kind of hard to use, so it's great for power users, but not something that I would want to force on anyone. I would probably have a SVN repo, and if people wanted to, they could use git-svn to access it.

subversion + TortoiseSVN + AnkhSVN (free visual studio plugin).

Subversion + TortoiseSVN.

Quote:

Original post by rewt We also use Trac for basic project management (e.g., defects, tasks, milestones, etc). Though not perfect (no multi project support) it has some excellent features such as the ability to integrate with a subversion repository. This allows me to commit changes in my source (e.g, a bug fix) and relate that to the ticket in Trac that describes the bug. So I can , in Trac, see the precise changes that resulted in the resolution of that ticket.

At my previous job we had that with Bugzilla. We used a combination of Subversion, TortoiseSVN and Bugzilla, with AnkhSVN being evaluated by ultimately discarded because most of our development was being done on Linux anyway.

I'm a fan of Perforce myself. It's free for up to 2 users, but you'll have to pay after that. It's really simple to set up (AFAIK it's Windows only), and you get a really good GUI and merge and diff tools with it.

EDIT: And, as KulSeran said, we also use this at work.

We use perforce at work because the update/commits are infinitely faster than SVN.
Besides the windows tools for perforce imho trump the interfaces in TortoiseSVN.
And there is a nice VS2005 plug in for it. (I'm sure svn has one too, but we didn't have that one at work)

Quote:

Original post by pinacolada I think DSCMs still have a few advantages in those situations. One is, instant local branches. Even on single-developer projects, it's nice to be able to make experimental local branches, so that you can make crazy changes without breaking the main version.

The only advantage over svn copy is the instantness, then. And I don't know if that's enough of a benefit. Does metadata about the branch get merged into the main repo? With Subversion, we simply maintain working branches (under /svn/devel), which the branch developer can refresh from trunk intermittently (to start new development) or merge back to trunk to conclude breaking feature development.

We also tag a collection of files toward a specific release, which allows for new files to be introduced to the trunk repository without affecting a build of the specific tag.

Quote:

As a side note, I don't know if I would recommend Git for company use. It's still kind of hard to use, so it's great for power users, but not something that I would want to force on anyone. I would probably have a SVN repo, and if people wanted to, they could use git-svn to access it.

Well, I'm going to be customizing whichever solution I go with, so it's as much a function of what the solution provides and how extensible it is.

The only source control system that I have used is Darcs. I like it and I will probably use it in future projects. But I don't know how it compare with other systems.

Quote:

Original post by KulSeran We use perforce at work because the update/commits are infinitely faster than SVN. Besides the windows tools for perforce imho trump the interfaces in TortoiseSVN. And there is a nice VS2005 plug in for it. (I'm sure svn has one too, but we didn't have that one at work)

I prefer Perforce to Tortoise SVN. We use it at work and i'd use it at home if i could.

Quote:

Original post by Oluseyi The only advantage over svn copy is the instantness, then. And I don't know if that's enough of a benefit. Does metadata about the branch get merged into the main repo?

Yeah, all the branch metadata is stored. It also remembers all the merges, so you can pop open the 'gitk' tool and see a connected graph of all the branch/merge history.

Having several local copies of a repo certainly gets the job done, but it's more awkward. Things like, diffing across branches, and merging across branches (without yet touching the public repo) are a little more difficult. Not that it's hard to diff/merge across directories, it's just Git makes these things ridiculously easy, so my standards are high :)

Quote:

Original post by Oluseyi Quote: Original post by pinacolada I think DSCMs still have a few advantages in those situations. One is, instant local branches. Even on single-developer projects, it's nice to be able to make experimental local branches, so that you can make crazy changes without breaking the main version. The only advantage over svn copy is the instantness, then.

And much more robust merge functionality. Merging branches is always an exciting high-risk adventure with SVN and most other non-distributed SCM's. [wink]

From what I've heard, Bazaar is supposed to be a really nice DSCM, with a nice API for extensibility.