4

I am using tortoise SVN with Ankh. I really have spent too much time tweaking and cleaning mess from time to time and I lost hope in educating each every developer on how to use things properly. I am sorry but I am fed up and tired restoring the repository/reverting/fixing merges manually, sometimes even having to write some code again.

So here's my question : Is there a chimpanzee-friendly solution for source control privileging Simplicity over Flexibility ? Projects and teams are small and I figured out that we just need VERY simple and basic chekout/checkin mechanisms, with no flourish, and limited functionality and features. That would help me stop being paranoid about projects integrity.

I know that there is no easy way to do this and there is minimum techinicity and discipline required, but I ended up wondering if we Really needed all that in our case, as in the long run, it causes more trouble than it helps.

Mehdi LAMRANI
  • 11,289
  • 14
  • 88
  • 130
  • I don't know anything more light weight then SVN. Probably I know not enough – abatishchev Jan 17 '11 at 15:27
  • Please define `VERY simple and basic chekout/checkin mechanisms, with no flourish, and limited functionality and features`. – Oded Jan 17 '11 at 15:29
  • What other tools/options have you considered, if any? – Jazza Jan 17 '11 at 15:31
  • @Jazaa I was thinking of Bazaar, but All solutions I was thinking of do not meet simplicity and light-weight requirements – Mehdi LAMRANI Jan 17 '11 at 16:02
  • 2
    The Agent SVN Subversion plug-in for Visual Studio has a file locking option which theoretically would eliminate the need for any form of file merging, since access to the file would be serialised. – jussij Jan 27 '11 at 04:52

5 Answers5

3

Your problem sounds like it has more to do with process and branching strategies than anything else.

If your developers know to always get the latest code before checking in and resolving conflicts locally, running all tests etc, you will already have a leg up.

Educate your developers instead of trying to use a dumbed down SCM (that in the future will probably not be adequate to your needs).

As for branching strategy - I had found that branch per feature is the most natural way to work and mostly avoids merge conflicts.

Changing SCMs will not help with your issues if you don't tackle process and branching.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
2

First, I would suggest that you force developers to clean up their own messes, not do it for them. By doing it for them, you are only encouraging them to stay ignorant. By all mean, be a resource and provide help for them, but make them do it themselves. They will quickly learn what they have to.

Second, there are few options that have the kind of integration with VS that most developers would like. SVN is one of them. Team System is another (but a much more expensive and complciated solution). Visual Source Safe is also an option, but it's really an old, out of date system that hasn't been updated since 2005 (and even that, that was largely a patch job to a system that hadn't been updated in 7 years before it).

If you want free, there is nothing worth using that is simpler than Subversion. Everything else will be ancient technology (like CVS) that will have even more problems. There are several free SCM's that are more powerful, like git and Mercurial, but you would have even more problems. If you're willing to pay, then many third party tools have better merge and visualization tools. One I like is AccuRev.

There are also some better commercial SVN plug-ins for visual studio that may help as well. I've not used any of them, but they may improve the developers use of SVN.

Erik Funkenbusch
  • 92,674
  • 28
  • 195
  • 291
  • although it is very simple to use, i would not recomment Visual Source Safe, too because when working via a vpn and the connection breaks its likely that your repository is broken afterwards, too – k3b Jan 17 '11 at 16:26
  • @k3b - In the 2005 product, Microsoft introduced a web based client/server model to VSS which solves that problem. I've never seen anyone use it though, preferring to continue to use the file based model. – Erik Funkenbusch Jan 17 '11 at 16:31
1

Try the combination of Mercurial and Tortoisehg as GUI. You can also use it from Visual Studio with VisualHG. Every developer is free to clone and manage her own repository. Once you reach an agreement you can push up to a colleague's repository or a central location.

To aid with adoption, you might convince others to watch the DVCS video on the FogCreek Kiln page.

See what-makes-merging-in-dvcs-easy and similar SO discussions regarding the relative ease of merging.

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
gimel
  • 83,368
  • 10
  • 76
  • 104
  • Umm.. seriously? You think a DSCM will be *easier* for developers to not screw up? Wow. – Erik Funkenbusch Jan 17 '11 at 15:44
  • Adoption by many of open source projects means that real life developers are actively using it. – gimel Jan 17 '11 at 15:50
  • 1
    @gimel - Just because many developers use it doesn't mean it's easier to use, and easier to not screw up. In fact, I tend to think the opposite is true. The more it's used, the more features programmers demand, the more complex it gets, the easier it is to screw up. git and mercurial have very steep learning curves, but are very powerful... like most open source software. And, as the saying goes.. with great power comes great responsibility. – Erik Funkenbusch Jan 17 '11 at 15:58
  • @Mystere Man - Good to feel understood :-) – Mehdi LAMRANI Jan 17 '11 at 16:20
  • @gimal : Mercurial seems to handle merges better than plan SVN. Do you confirm that ? We had MANY MANY merge issues with TortoiseSVN. – Mehdi LAMRANI Jan 17 '11 at 16:32
0

I would say that every developer that works in a team should have a strong understanding of source control principles. Maybe you should get better developers! :-)

To answer your question I have always found Team System wonderful and very flexible. With such good IDE integration, it can be configured to ensure best practice in source control. However, it is quite a big source control system so may be over the top for your purposes.

Mark Robinson
  • 13,128
  • 13
  • 63
  • 81
  • Good developers have a cost that my Boss is not willing to leave away. We have been outsourced... :-D As of Team System, it is oversized considering our needs I think... – Mehdi LAMRANI Jan 17 '11 at 15:53
0

I believe the issues is more of process than product. Strict written documentation and process might work Keep it as simple as possible. You might make adherence to the process a contractual obligation.

That said I have had very good luck with Visual SVN for Visual Studio. It is easy to use and integrates well.

If that is too hard, might revert to TortoiseSVN which is pretty idiot proof.

As for an alternate super simple product I know not of such a product, but if you really need something lightweight, then datestamped and named zip files is a the poor and ignorants form of source control. Merging and restoring is a bitch though.

Development 4.0
  • 2,705
  • 1
  • 22
  • 17