- Tightly controlled development will remain the providence of centrally managed source control.
You can still centrally manage source code with Git.
Iāve recently become a fan of Mercurial, one of the distributed source control solutions. Like subversion, itās got a simple clean syntax, and is free open source. While I donāt even remotely agree with Torvaldsā āsubversion is evilā position (in fact I really like subversion- Itās my favorite of all the centralized systems) there is some convenience to the Distributed model. My personal favorite element of it is that you can commit to a local repository, meaning you can work and save your changes while offline (say, on a plane or something). Then when you get back to somewhere with a connection, you can push those changes to a centralized (potentially off-site) repository. I know some people consider it ācheatingā to still have a repository considered to be the central one- I really donāt care. To me, Mercurial is like subversion with a little more flexibility tossed in. Iād recommend giving it a shot.
Curious thing. Yesterday I was looking into installing Subversion on my Windows machine so I could play with Scala.
Now, many years ago I was a FreeBSD committer and, as such, comfortable with CVS. Since then I have been using Dimension/PVCS, and not as a programmer, and Iām fairly happy with it.
But, yesterday, I was not happy. I didnāt like what I saw with Subversion. Too heavy, it seemed to me. I looked up an old favorite I never got the chance to use, Darcs, and I wasnāt happy again ā no Eclipse plugin and, frankly, Windows install seemed an uncertain proposition.
I might check Perforce. The FreeBSD team was using it about the time I was a committer more in name than in actions. For my purposes, maybe it will work fine.
Anyway, let me drop a piece of wisdom to those who are considering version control just because of this article. One change, one commit. Do NOT ācheckout at morning, checkin by eveningā.
When you do a commit (check in, or whatever you want to call), you are supposed to explain what was the the intent. What were you trying to do? I say this because my usage of versioning systems have always been history-heavy. If a version control system doesnāt have āannotateā, it sucks.
The thing is, once you find a bug, it is very important to understand why the bug is there. The bug, very often, is actually doing something else correctly, the bug being a side effect. So, to avoid breaking something else when fixing a bug, and even to help devise a fix for the bug, itās very important to know when the code came into being, and what was the intention of the change.
It might also help to make clear what is working or not on your development methodology.
Plastic SCM http://www.codicesoftware.com/xpfront.aspx looks interesting, but I havenāt been able to find any good reviews of it. They are advocates of a branch per task philosophy which makess more sense to me than mainline development.
Anyone heard of it or have any opinions?
would be better if you had taken another 5 minutes to show its integration with Netbeans.
ā¦i knowā¦some people are never satisfiedā¦
Hereās a good place on how to set up svn+trac -
http://inner-rhythm.co.uk/TV/
And you wonder why people choose SourceSafe over subversion??
Please do not use SourceSafe.
http://www.codinghorror.com/blog/archives/000660.html
Subversion takes a tiny bit of work because itās free, but there are also lots of commercial source control providers (Team System, Perforce, Vault, etc) that are infinitely better choices than SourceSafe.
The real question is whether a decentralized tool can ALSO meet the
development needs of a centralized development environment.
You should be able to work as ācentralizedā as you want with pretty much any revision control system Iāve seen.
However, I think a lot of people will be suprised to find, as I was, that their development environment is only rigidly centralized because their old revision control tool forced it to be. The human processes tend to flow organically around the limits of the tools you use. You can end up with a lot of unwritten meta-data that has to be learned by new employees. You may never even notice this if you donāt have any experience with different tools.
Thatās why Iād suggest everyone spend a little time playing with new tools when they can. Even if you never use distributed revision control (or functional languages, or Unix, or Emacs, or ā¦) it will change the way you think about the tools you do use. Expanding your bag of tricks will make you a better developer all around.
Give me a distributed VCS that doesnāt use huge hex strings to identify revisions, works decently on Windows, and has Eclipse integration; and a sourceforge-like site supporting it, and then I might start looking at the distributed model.
till that exists, svn will do 
Interesting, Iām currently following the Blog of Brian Di Croce where he presents the steps to install your own CIE (Continuous Integraton Environnement). The first step is the installation of subversion, not as in detail as yours, but quite interesting. He also presents the installation of TeamCity from JetBrains.
You might be interested, http://blog.briandicroce.com/
Sylvain
After looking at svn and using it for a couple years, Iāve decided that it has a number of serious problems. Iāve posted some extensive commentary here:
http://blogs.sun.com/smarks/entry/why_i_don_t_like
sāmarks
Well reading some comments, Iām wondering if some have ever use Subversion before ? My experience with sourcesafe were a nightmare, corruption of data was one of the problem I got. I was using it though, I did not configure it myself so I donāt know if it was easy or not.
But I have setup many subversion and never got any problem. On linux itās a matter of simply install a package and change the config file, so pretty easy. I also setup a Trac environement for the research project Iām in, itās really useful and easy enough to skip the 50$ License for JumpBox.
Iāll look in Mercurial tough, I did not know it and I think it could be more appropriate for our project at http://sonia.etsmtl.ca
the warning against sourcesafe is just ab it of personal choice. For some programmers it is the far better choice than subversion with all the lacks of svn and vs integration
There are several free-ish (as in $5 a month) repository providers on the web. Well worth checking out and useful for small teams without the hassle of setting up the repository yourself.
Iām sure there are SVN hooks into VS - both products have been around far to long for this not to be the case.
Donāt know if anyone else had this issue w/ setting up the root level folder for the new project on their Windows box:
Tutorial instructs:
set SVN_EDITOR=c:\windows\system32\notepad.exe
Results in:
sh: c:windowssystem32notepad.exe: command not found
svn: system(āc:\windows\system32\notepad.exe svn-commit.tmpā) returned 32512
Correction:
set SVN_EDITOR=c:/windows/system32/notepad.exe
/\Yes, coffee is the great illuminator./\
If you search for āsubversionā in the vmware appliances page, you get 40 hits:
http://www.vmware.com/vmtn/appliances/directory/cat/53
Has anyone used a subversion appliance (or a separate computer on a LAN) with something like no-ip.com ?
If you just want to use SVN for working on local file repos you donāt need to go to all that hassle, just download install tortoiseSVN, it has everything needed to create and work with local repos without needing any other setup.
SVN sucks when you need to manage lots of code and lots of branching/merging. Having used perforce before, I can attest that SVN really does suck when it comes to merging - everyone hated on my team except PHBs who loved it because of the ZERO sticker price (but didnāt consider the lost productivity time using the tool).
I found that merging or back-merging to a main trunk to be a chore simply because you had to physically keep track of revision numbers that you want to merge. I hear SVN 1.5 will fix this, but the world is still getting burned using 1.4.
Not to mention that there are a handful of backmerge processes that you can follow, depending on your branching strategy only complicates matters further.
Sheeshā¦merging shouldnāt be that hard.
Linusā argument on why central source code management sucks: if you have a million users all operating in check-out, work in disconnected fashion, and then having them merge their changes into a main trunk is very difficult due to the fact that kernel code is prone to breaking a lot when data structures change, APIs change, etc.
So either you give EACH user their own private branch within a central repository which is very expensive storage and compute wise and huge server burden OR you go to distributed mode where EACH user HOSTS their own repository.
Now if Linus wants to see your changes, he simply checks out YOUR repository. If you want some changes integrated into your repository, you simply pull changes needed from one repository and add them to yours!
Yes the concept is similar to private branching, but more flexible I think.
The question is, whoās repository is GOLDEN, e.g. the official repository for code releases, and Linusā is the declared one here.
kashif
Notice that when you gonna write
sc create svnserver binpath= āc:\svn\bin\svnserve.exe --service -r c:\svn\repositoryā
you must respect every whitespace (epecially the one after binpath=)