13

At work we use SVN, but in name only. We don't branch or merge. We keep two copies of the repository, one serving as the "tag" branch that gets copied when we do a deployment and kept for bug fixes and immediate "this has to go live asap" type of features. We have to remember to copy changes made in one copy to the other copy (the "trunk"). We have a dozen projects inside a single folder in the repository, instead of splitting them out. In short about the only thing we use SVN for is being able to commit. Everything else is done manually.

I've been evaluating Mercurial; I have used Git in the past (I'm the only one on the team who has used a DVCS), and I'm picking up Mercurial quickly. I'm debating introducing Mercurial to the rest of the team as a "better way" of doing things because branching is a snap, merging is a lot easier, and we can commit things locally to our heart's content and only push them to the central branch when they're ready. We would get all of the benefits of SVN (and we aren't getting many benefits right now anyway since nobody really understands SVN) plus for new features we don't have to have tons of unversioned files floating about so if we have to rollback we're screwed. The workflow seems a bit simpler - we just have to remember that "Commit" is local and "Push" is like SVN's commit, and "Pull" is like SVN's Update (what the team refers to as "get latest").

Is this a good approach to take? Keep in mind that the team is very flexible and will go along with anything that will improve our quality of work and make how we do things easier - the CIO even asked me when I mentioned how we weren't using SVN to it's potential "Is there something better we can use?" so he's on board with it too.

Improve this question
18
  • 13
    HgInit - It starts with subversion re-education, which I think you'll find useful.
    – yannis
    Commented Dec 21, 2011 at 12:33
  • 20
    Are you not afraid that they will end up using Hg poorly as well?
    – Oded
    Commented Dec 21, 2011 at 12:35
  • 6
    I think a DVCS would be a horrible idea for your situation, as the learning curve is higher and you clearly as an organization are struggling just to utilize basic features of SVN. Moving to DVCS should only happen after you are utilizing tags, proper repository organization and proper merging techniques in SVN and finding that it is still lacking for yor needs.
    – maple_shaft ♦
    Commented Dec 21, 2011 at 12:39
  • 2
    @WayneM Choosing to use SVN over a DVCS isn't necessarily flat out wrong. Some people (myself included) don't have any problems with merging in SVN and find that the added complexity of DVCS outweighs the perceived benefits, especially if you are a smaller localized team. I will probably not take DVCS very seriously until I end up on a large development team where merging is a huge pain point.
    – maple_shaft ♦
    Commented Dec 21, 2011 at 13:01
  • 4
    @maple_shaft I will probably not take DVCS very seriously until I end up on a large development team Or until you end up on a distributed team. We are a small team (5 people) working from 3 locations (and sometimes 5, when we don't feel like getting out of bed), and the switch from svn to hg was a welcome one...
    – yannis
    Commented Dec 21, 2011 at 13:20

6 Answers 6

Reset to default
15

Yes.

If you replace "SVN" with "Perforce" in your OP you've pretty much got the situation I found myself in when I started my current job, even down to the manual-change copying. Two years on we're on Mercurial and everyone agrees it's been a great change.

We have the ability to branch and merge per support case, which is unbelievably useful for QA, and the ability to create any number of throwaway branches and repositories whenever we see fit, which we can then build and verify in our CI server, then deploy to a cloud test environment and verify functionality. This has been of huge benefit in terms of peace of mind that when we do a live deploy, we're almost 100% sure that it will work (sans environment/DB issues, which are obviously out of the scope of the VCS).

Basically, what we gained from switching to mercurial is breathing space. We no longer have to worry about the cost of a branch, or the horrific merge sessions that inevitably used to follow, everything is much much easier. We also use FogBugz quite heavily so the tie-in to Kiln (their hosted mercurial) is really helpful.

The comment about the hginit site is spot on too, as an outline for a version control workflow that actually works (assuming you adjust it for your company's particular QA workflow).

The only possible flaw in moving version controls is that you will need someone who's really a driving force behind the change, who's happy to read up on the subject matter and really use the tooling to the best of its potential, which you seem to want to do.

I don't agree with the comments about team size and team distribution relating to whether to use DCVS either. Really, it's about CODE distribution. If you have multiple development cycles happening in parallel, either support cases on a legacy system, or a bunch of features or even new systems (which by the sound of it you do), you will benefit from using a DVCS.

Improve this answer
11
  • 3
    -1, if the developers are already having such issues with Subversion, it's extremely unlikely they'll "get" a more complex system. The correct answer is, as the comments on the question say, a re-education of how Subversion (and VCS in general) works...
    – Izkata
    Commented Dec 21, 2011 at 15:43
  • 1
    @EdWoodcock, I think what you observed might really be due to the fact that your team got to start with a "clean slate". The comprehensive change of VCS to mercurial meant that everyone had to start fresh and could no longer depend on the bad habits they had been using in SVN. Many times it is easier to overcome bad habits "starting over" in another context (in this case mercurial).
    – Angelo
    Commented Dec 21, 2011 at 17:27
  • 2
    @EdWoodcock: Perforce may have the worst branching of any VCS still in use. Branching in SVN is much easier.
    – kevin cline
    Commented Dec 21, 2011 at 17:58
  • 1
    Whatever version control system is used, I think it is important to "lay down the rules" and spend time to go over all the usage scenarios with your team. People aren't born knowing how to do branches, tags and check-ins, different teams do these things in different ways and VCS systems don't enforce one workflow over another. If the members of the team aren't all on the same page in terms of expectations and usage, version control becomes a nightmare. These are problems that are common to ALL VCS systems.
    – Angelo
    Commented Dec 21, 2011 at 18:56
  • 1
    @ChrisS That parable is more applicable to a standard VCS where there is a cost of branching. Plus, it's talking about branching, committing, then merging again, which <i>you do every time you clone</i> in a DVCS. Plus, I've just outlined why the approach really works for us; being dogmatic about methodology is fairly silly.
    – Ed James
    Commented Dec 22, 2011 at 11:10
21

A different tool is probably not going to solve your problem, I'd say you should read this article, I found it most helpful:

http://thedailywtf.com/Articles/Source-Control-Done-Right.aspx

I think the main point of the article is summed up here, but please do read it:

In The End: Not Really About The Tools

In all of the time I’ve spent working with and integrating different source control systems, I’ve come to one conclusion: it’s not the tool, it’s how you use it. That’s a terribly hackneyed statement, but it seems especially true here. When used to properly manage source code changes – labeling for builds, branching by exception, etc. – even the lamest source control system (*cough*SourceSafe*cough*) will far outperform a Mercurial set-up with a bunch of haphazard commits and pushes.

Improve this answer
4
  • 6
    +1, it really is not about the tools. SVN is perfectly capable as is perforce.
    – Angelo
    Commented Dec 21, 2011 at 15:35
  • 1
    This is all about people, not tools. I have seen nicely managed projects still using Concurrent Versions System for version control, as well as terrible projects running GIT or Mercurial..
    – Alexander Galkin
    Commented Dec 21, 2011 at 21:09
  • It's not really about tools, unless you've got superior ones to compliment the source control provider like github, bitbucket
    – Chris S
    Commented Dec 22, 2011 at 9:34
  • 3
    Whilst I agree that it is how you use your tools that count, it is also the case that different tools lead you in different directions. Tools like Mercurial lead you down a path of simplicity and flexibility. Git leads you down a path of complexity but extreme flexibility, Subversion makes some things easier than others, so steers you away from the difficult and fiddly things, while Visual Sourcesafe leads you down a path of extreme inflexibility and head-banging frustration. *8')
    – Mark Booth
    Commented Jan 5, 2012 at 10:11
10

No. Technology rarely solves this kind of problem.

Mercurial is more complex than Subversion (yes, branching and merging is better, and perhaps easier, but Subversion's model is much simpler than Mercurial's). If you are using Subversion in such a braindead way, you might end up using Mercurial:

  • a) Adequately or better
  • b) Inadequately, but better than your current usage of Subversion
  • c) As inadequately as now
  • d) Worse than now

c) and d) sound like the most likely outcomes. Write down why you think you'll end up in a) or b).

Improve this answer
5

I can't speak to how large teams work, but for small teams a lot of those big SVN issues aren't really SVN issues... They're development issues. If you're not following modern development standards (most importantly, doing continuous integration), then versioning turns into the exact mess you're describing... Before leaping to a new system be sure to perform a true root cause analysis on your issue...

Improve this answer
3

No. Tools aren't replacement of methodology.

If you don't use Subversion as SCM, you can don't use Mercurial also (and it will happen most probably)

Improve this answer
2

SVN can do what you need it to do and there is no need to change horses mid-stream for a dubious pay-off.

Whatever you do you will have to overcome a trust issue. Someone has to be able to convince everyone to change their workflow. This is not easy even in the best circumstances, even if you have logic and facts on your side. It is one of the hardest things to do in an organization. If you botch it or it goes rough, you lose trust and it will be very hard to re-gain that trust.

There are a couple of things that I know people have tried successfully. Perhaps one of them will work for your team:

  1. Bring in a "coach" to provide a series of workshops for the team. This will likely have to be an external person (ironically, it is often easier for many teams to trust an outsider than it is to trust someone on the team). It has to be someone that knows her stuff inside-out and that can effectively teach these skills to people at all levels of understanding and devise a pragmatic plan for rolling the new VCS (*) out to the team's workflow.

  2. Start a "skunk-works" project to test-drive and validate the new VCS on a small side-project. Choose a couple of "alpha" developers that are willing to try new stuff and don't mind racking up a bunch of unsuccessful experiments. When the skunk-works is able to demonstrate CONCRETE irrefutable improvements in workflow, then you can then attempt to roll it out to the rest of the team and you have a couple of evangelists to help you do it.

(*) by "new VCS" I don't necessarily mean mercurial or git, it can also be SVN (done right).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.