views:

406

answers:

9

I desperately need source control to manage projects between more than one developer.

A long time ago I used Visual Source Safe and it worked quite well.

Can anybody recommend a free substitute? I have the following basic requirements:

  • I need to host the repository on my own server.
  • I do not want extra clutter within my source files, like CVS does.
  • I need proper check in / check out, so that nobody can change a module until I've checked it back in.
  • I don't want / need source code merging / branching.

We use Delphi for web development, so many html files, images, sql files, etc.

Any recommendations?

+12  A: 

I'll always recommend subversion with Visual SVN for server software and Tortoise SVN for the clients. You can exclusively check out files, so that nobody else can edit them, although that's not the default behavior. The only "clutter" it adds is a hidden .svn folder in every directory that is under version control.

David Hedlund
I SO hate that .svn folder!! Using dreamweaver to sync with my web sites, it takes forever to compare those little files as well.
Hein du Plessis
yes, i'll admit to never having sync'ed websites with dreamweaver =) doesn't your software come with options to ignore certain folders, tho? based on how they're named, or, say, the fact that they're hidden...?
David Hedlund
Why does the OP not just do a `svn export` to get rid of the .svn directories?
iWerner
I suppose there are way to avoid the dreamweaver issue, but it only need to slip through once from anybody then they're on the server and they slow down compares.The same for FTPing files up. Why can't it keep a single database to keep track of versions :/.
Hein du Plessis
If you are publishing files to a server, I strongly recommend WinSCP. You can set up ignore folders, such as `.svn`. Don't you run into this problem regardless? Many system folders on *nix systems are preceded with a period.
Paul Lammertsma
Thanks agian Paul for all your comments - I only work on Windows. WinSCP is great, but I have to use the built in FTP / SSH of Dreamweaver etc. MacOS also insist in spreading millions of files inbetween user files. Freaks me out.
Hein du Plessis
http://www.communitymx.com/content/article.cfm?cid=9C6DA. dreamweaver has an svn integration.
bmargulies
alright. i think that should effectively terminate the discussion =)
David Hedlund
Great - but now I have to upgrade my version of DW, which I'll do if it helps.What about non-text files?? I have office docs, ER Diagrams, Delphi forms, GIMP images, etc all being worked on on the same project - how does one handle that with svn?
Hein du Plessis
Svn handles versioning of those files as well. You can't merge or diff them, but you can roll back to previous versions etc
David Hedlund
thanks, but would it prevent or manage two developers working on the same file?
Hein du Plessis
with svn, you can have it any way you like. you have the option of doing an *exclusive checkout* which means you're the only one with the permissions to edit the file at hand.
David Hedlund
svn it is then, I'll bite my fist and ignore the clutter :)
Hein du Plessis
+12  A: 

Git or Mercurial.

  • both are distributed and fast (each repository can act as 'server')
  • no extra clutter just one .git or .hg directory
  • you can pull changes from trusted or verified sources
The MYYN
There is no "check out" though as the author requires
artemb
I'm all for these systems, but they have nothing to do with what OP wants.
Michael Krelin - hacker
Thanks, checking. Oh no check out??
Hein du Plessis
Seems Git is not so Windows friendly, requiring CygWin to run. Surely there must be a VSS equivalent somewhere out there.
Hein du Plessis
@Hein - no it doesn't. msys variant runs very nicely without cygwin (i love git, cygwin - not so much, therefore ...) and if you put git extensions, or smartgit you can turn in into a practically non-cmd vs.
ldigas
Thanks, trying git - I'm downloading the "preview" beta - can't find the latest stable.
Hein du Plessis
I think, considering all the remarks made in this topic, a solution with only one repository directory would be best. If Mercurial accomplishes this, it seems like Hein's best bet.
Paul Lammertsma
I've got git installed, but asks me about a directory. My other developers are off-site. I'll need them to connect through ftp or ssh etc. Can this be done?
Hein du Plessis
I would also add Bazaar to that list, since its similar to those. (DVCS)
mathepic
Thanks, will check it out
Hein du Plessis
@Hein none of the DVCS solutions answer your 'must be able to check out' criteria. If that is still a must have for you, don't waste more time on DVCS's. None of them will do that, as it requires a central control point. (and before people flame me, I was responsible for the introduction of HG to the dev team I work on).
Mikezx6r
@Hein TortoiseGit works fine with Windows. It is not so perfect as TortoiseSVN yet, but it works.
DiGi
+6  A: 

If you insist on zero-clutter, and also free, you have limited choices. If you are open source, you can have a free copy of perforce. No clutter. SVN has clutter like CVS: a .something directory in each directory. git and hg just have one directory of clutter per clone.

If you absolutely insist on a checkout model, you have to give something up. P4 will do it, but none of the others will very well. Most people are more concerned these days with allowing disconnected operation than with a concept of locking. even svn lock only prevents checkin, not starting to modify.

There are other more obscure systems out there (e.g. arch) that you might look into.

bmargulies
Like git, with a .git in every directory, like bazaar with a .bzr in every directory, like mercurial with a .hg in every directorym like...
BeowulfOF
Looks like your stuck with a checkout/checkin approach, or adopting a different publishing strategy.
Paul Lammertsma
With Git (and IIRC also with Mercurial you have `.git` directory only in **single place** - top directory of your project; I don't know about Bazaar, but I guess it is also true for it.
Jakub Narębski
I just checked. .gits are everywhere.
bmargulies
@bmargulies... then you're doing it wrong - git only puts one .git directory at the top of your repo
David Claridge
I can't figure out how to have a remote repository.
Hein du Plessis
Oh, bats, I cd'd to the wrong place.
bmargulies
I can confirm that .bzr is only in the top directory.
mathepic
+2  A: 

I discourage the checkout/checkin approach. A decent version control system should be able to merge changes. This provides you with plenty of choices: CVS, SVN and Git.

As for "clutter" in your source files: I don't consider repository directories (e.g. .svn or .git) clutter, as this allows you to copy the repository structure.

Nevertheless, in SVN (not sure about Git) you can lock/unlock a file, basically mimicking the VSS checkout/checkin.

Paul Lammertsma
I dont trust merging. My colleague might be removing a declaration that I'm actually implementing at the same time. Every so frequent manual intervention is needed, if not an outright buggy final merge.For opensource development, merging is crucial, but I don't need more ways to introduce bugs.
Hein du Plessis
Unfortunately, the developers of free source control systems don't seem inclined to agree with you.
bmargulies
@Hein - experience (mine and others) suggests otherwise - not a huge number of merge issues except from divergent branches and those are usually (happy to accept not always) easy to resolve. Locking doesn't stop another user stomping on your changes either -*especially* if you're working on changes in the same area - its just makes it slightly more challenging.
Murph
@Hein du Plessis: When I first started at my current job, I would have agreed with you about not trusting merging, but our 75+ person engineering team has been doing this with Perforce for over twelve years (and over 600,000 check-ins). Sometimes you need to manually do a merge when Perforce can't figure it out, but the vast majority of changes are merged automatically. We have had the occasional botched merge, but those are exceedingly rare.
Graeme Perrow
Locking a file will not prevent your colleagues from wrecking your code after you unlock it again. As for avoiding merges altogether, this is something of the backbone of a reliable version control system. In the scenario you put forward, using VSS, your colleagues would instead have to wait for you to finish.
Paul Lammertsma
I'm in complete agreement with my subversion-loving counterparts. My friends and colleagues collaborate wonderfully using SVN, only ever running into problems with the occasional conflict (though easily solved with tools as WinMerge) and, as stated, merging branches.
Paul Lammertsma
I know! Probably because merging is essential for developing opensource.
Hein du Plessis
I assume that with open source you are referring to the number of developers. Yes, the more powerful the merging strategy, the better it performs for merging multiple revisions. However, if there are few revisions, the likelihood of a conflict is fairly low. So in this sense, I don't see any convincing argument against this strategy.
Paul Lammertsma
@Graeme: That's impressive. I hear similar scenarios everytime when I bring up the subject. I think I'm going to risk it...@Paul: VSS used to change all the files to read only that are checked out, so whatever IDE you use, it will warn you that they are read only. I'd prefer my colleagues to wait for me to finish, we work on many projects concurrently and again, I feel safer knowing that they're not changing declarations that's going to break my module after I merge it.
Hein du Plessis
This really demonstrates that it has to do with preference and style! As a final remark, I think two points should be made. Version control will always allow you to revert a change, hence allowing you to recover the "unbroken" version. As your working environment involves users that could potentially mess up your FTP directory, it seems to me that SVN is nevertheless not a solution. (Unless you `svn export` to the server, but one mistake is a headache.) Whichever way you go, you're going to lose. Drop SVN or drop FTP.
Paul Lammertsma
@Paul: I've tried merging and had an instance where a co-developer removed code that I depend on for my version to work. The merger did not recognise this and it was a time consuming excercise to make the system accept the change. To avoid this, I prever check-in / check-out. But this is not an option if you have a large developer base, agreed.FTP is only used when sending final versions of web sites to the hosting server. If that version gets corrupted, no biggie, just delete it and re-upload from the source.
Hein du Plessis
Also, if I go the merge route, what about non-text documents? I have Delphi forms, images, word docs, visio diagrams, ER diagrams and many other binary files that changes just as frequently.How does that work?
Hein du Plessis
You'll get a conflict if they are committed out-of-sync. You can resolve conflicts in Microsoft Office very elegantly in Office using the collaboration functions. Some conflicts in binaries can be resolved using WinMerge and other applications. Delphi forms and ER diagrams are text, aren't they?
Paul Lammertsma
Yes, but not project files or resource files. ER Diagrams are built using ERWin, also binary. So are many other file types making up the final product.Not everyone has access or is familliar with office collaboration tools.I just want a check in check out :(
Hein du Plessis
Certain non-text documents can be compared using Beyond Compare, which natively knows how to diff such things as binary Delphi forms (probably because it's written in Delphi), etc. I have it set as my default diff tool in TortoiseSVN. I can't recommend it highly enough.
Conor Boyd
Communication with your fellow developers is required, whether you use locking or not. The examples you (hein) gave are examples of failed or miscommunication, and would not be solved by locking.
Warren P
+1  A: 

Hmm, define "clutter" - to my mind a hidden directory per folder isn't clutter, frankly it hasn't been an issue at all (for reference, 7 years of first CVS then Subversion and prior to that VSS and something distributed the name of which eludes me).

Subversion is excellent and installation is almost trivial with VisualSVN server and use is straightforward with Tortoise as a client. Locking of files is an option, not a good one in the general instance but its there for binary files if you need it. This is probably the closest match to your criteria and I like it. A lot.

For personal use I'm playing with Mercurial - but not done enough to say more than that it works (and of course like most DVCS it fails your "lock" criteria). DVCS is different and has some issues.

If you have money, Vault (http://www.sourcegear.com) is worth a look - especially if you used and liked VSS since it started out as a "better" VSS though it has evolved somewhat. Worth visiting sourcegear just to read Erik Sink's thoughts on version control.

As for the rest, whilst I'm sympathetic to a wish not to (have to) merge stuff, writing off tagging and branching is pretty much the same as saying "I don't need version control" - it turns out not to be the case.

Murph
My primary requirement is to avoid developers working on old versions. Branching etc is great, but required if you develop for individual clients.To me the core feature of source control is to be sure everybody is working on the same version and to be able to go back to previous versions.
Hein du Plessis
Fair points - from the sound of things tagging is more important to you than branching (this version went live and this one and this one). Branching is relevant to the "go back" case - in particular to allow you to fix issues with a released "site" or otherwise make changes when the "in development" site isn't in a fit state.
Murph
Ok, thanks for clearing that up. I don't need anything that sophisticated. Just a single branch, only 1 live version.
Hein du Plessis
+1  A: 

SourceGear's Vault is free for 1 user, and it gives you checkin/checkout plus merge-style operations. It also works totally clutter-free. I have been using it for some time and it works wonders. Transition from SourceSafe is especially easy, and integration with IDEs such as Visual Studio or Eclipse is very good.

CesarGon
Free for one user, great, but if you're one user, you can't get versions confused :) I'll check it out too, and fork out the money to get it on my other developers desks.
Hein du Plessis
I get your point, sure. :-)
CesarGon
Hmm, so I don't qualify as just one user then?
SamB
THis is the most like what you're used to (VSS) but cleaned up considerably, and not horribly broken like VSS was.
Warren P
+2  A: 

You might like to investigate Team Coherence (http://www.teamcoherence.com). It doesn't create special folders and has a Delphi bent to it. For example, it groups .pas and .dfm files together by default. Help is excellent. It's also now free for a single license. I've been using it for years after previously using CVS and FreeVCS.

Pete
Thank you, pricy, but probably worth it.
Hein du Plessis
To add to it, TC is written in Delphi :-)
Remy Lebeau - TeamB
+1  A: 

No one is recommending Bazaar, so here I am, I use it in my everyday work with Delphi projects. It has a diff viewer that rocks, and that, for me at least, makes the difference with the other svn-like repositories.

zzzzzzzzzzz
Except that it's a DVCS and is not lock based. Which the original poster wants. does it have a .bzr folder per repo or per folder? That's also something the OP didn't like. In short, none of the open-source DVCS meet his requirements.
Warren P
+1  A: 

You should read a bit and learn a bit before you consign yourself and your fellow developers to living in the dark-ages of version control.

Visual Source Safe and the locking model of version control are dead. Most people have moved on. Those that have not are usually afraid of (or loathe) the idea of branching, and merging. Once they see that branching and merging can be easier, and more effective, then they can move onwards and upwards into a new world of version control options.

Ask yourself a few of these questions:

  1. Would I like to separate the act of creating a new feature from the act of inflicting it on other developers, and on the final product (my live website)? If so, then I need branches. One branch = No effective version control.

  2. Have I asked the other developers who will be working with me, what practices they find effective in multi-developer projects, and do they agree with me that locks are the way to go, or am I unilaterally enforcing my way of working with them? (You can have foo.pas for today, but try to get it checked in by 3 pm because I need to make a change to method bar inside foo.pas, later today.)

  3. If I state that I want to make sure developers "avoid using old versions" do I have reasons for that other than that I hate or fear merging? Can we not think of any ways to prevent "using old versions"? Also, can we not think of any reasons when using old versions might be exactly what you have to do? If you used a non-locking tool like Subversion, why not say "please update before you commit". Then you will never have to merge, but if someone wishes to work with a non-changing version of the sources while developing the feature and then wishes to do the merging themselves, and you never have to merge yourself, you could insist that your work be done with locking (using subversion) but allow others the freedom to use a workflow that solves their problems, instead of yours.

  4. Suppose (as you said in comments above) someone is removing something that you are in the act of creating. Wouldn't it be nice to see a complete list of his changes and say "I would like those changes gone, without removing other changes made by other people". This is known as working with "changesets" and is a key feature of DVCS like Mercurial (hg) and Git. In fact, the ability to prevent other people from modifying YOUR local repository willy-nilly, but rather making changes, which you can then review, and either accept or not accept will always be better at creating coherence on your (master) copy of the repository than any localized, centralized locking model can ever be.

W

Warren P
TeamCoherence uses the locking checkin/out model, but still supports branching and diff merging. I always do a diff on checked in code before checking in new code.
Remy Lebeau - TeamB
It's interesting that 1 developer is free on TeamCoherence, but its $329 per developer, for the next 5 developers after that. It's an interesting hybrid design to be primarily lock based, and still support branching and merging. It might be the closest thing out there to what the original poster was asking for, except for the money bit.
Warren P