|
As soon as you are working with different branches of a project, you can feel the magic.
The leap of enlightment, for me, was to realize that I am no longer managing revisions, but changes between revisions, and that I can carry them around freely.
|
|
|
|
|
I've talked to an expert who knows both Git and SVN very well, and he told me that either tool is useful, depending on your team/project: Git is prefereable for distributed development, SVN has it's advantages for local development, or in small teams.
In any case he said that if you're using SVN - especially in combination with TortoiseSVN and AnkhSVN - and you're not doing distributed development (such as Open Source projects), then there's no reason at all to switch to Git.
I do read a lot of postings from people who seem to be happy using Git, but most of them do work on distributed projects, so I can totally understand why they prefer it over SVN. I haven't read a single reason in favor of switching from SVN to Git that holds for single-developer projects though. (or small local teams) I'd be glad to hear a few.
|
|
|
|
|
Well I am one such developer who recommends a dvcs or single man teams. The reason is not the distributed aspect of it though. It's the easy true branching. I always keep a released and a development branch and I can switch to any version easily using a graphical representation of my versionning scheme.
I'm not a fan of git because of the complexity and of how easy it is to break things. I prefer mercurial with tortoisehg. Fossil is interesting but last time I checked (a long time ago), it lacked integration with Windows explorer.
Whatever the tools, you need a good branching scheme. A dvcs just makes it easier.
|
|
|
|
|
Interesting. Thanks for the input.
I used to consider branching in SVN difficult as well, but it did greatly improve in one of the last versions. I'm still not using it enough to tell if a tool that were even better at it (if it is) would be a help.
I did read through various introductory articles on GiT, and found it incredibly hard to wrap my head around its philosphy. That's where I went with SVN, it was just so much easier to understand and make work, fully integrated into VS, too.
I didn't check out Mercurial though. Maybe I should.
|
|
|
|
|
My experience comes from a small and local team, too.
I came from a CVS (hated it) and SourceSafe background. Dabbled a bit with SVN, but it felt a bit like "VSS with merge instead of exclusive checkout, until they added some kind of exclusive checkout".
Git drastically changed how I use source control. Instead of a necessary burden, it has become a tool I use to solve problems. I don't know if I would use SVN differently now with that experience.
Some thoughts:
Stage/Checkin lets me hack code the way I like, and clean it up (group into separate commits).
The local repository deals solves a conflict I always had between "making incremental commits" and "keeping the main repo clean": I can do micro-commits, create branches for incomplete ideas, etc. These "dirty commits" do not even appear in the public repo.
When I'm done with a feature, I can "clean up locally" with an interactive rebase - grouping commits together, sorting them (e.g. if there ar two features developed in parallel), improving comments etc. before I put it on top of the main branch.
The "work unit" is not anymore a revision, but a change between revisions. A cherry pick easily gets a bug fix onto another branch. I can have a local branch where I "kick out" individual commits, I can decide ad hoc to create a "beta branch" that includes only selected commits from the dev branch.
GIT indeed is f***ing ugly to get your head wrapped around. Even after the initial get used to, it took a while to accept that most tasks take two (or more) git operations:
commit changes to a private repo: checkin (to the local repo) and push (from local to remote private).
getting code is a fetch (from remote to local repo) and a checkout (to get the code locally).
Integrating changes with the main branch is a fetch (get the remote changes into the local repo), rebase (put your local changes on top of the changes of the remote changes) and a push (send your changes to the remote repo). etc.
Ooops. To long.
|
|
|
|
|
I'm also a huge Mercurial "evangelist". I'm still in the process of trying to bring my department out of the dark ages, and Mercurial seemed to have the quickest, cleanest installation process under a Windows environment, and the learning curve (from zero) was not terribly daunting.
I also tried SVN, but it was difficult to manage merges and branching well. And I have yet to manage to get a working Git configuration working under Windows (maybe just haven't found the right instructions yet?). So Mercurial won out in our office. Plus, the DVCS makes it much easier when one of us has to travel to a customer site for field work. Not having to have a constant connection to the central repo is a huge asset.
|
|
|
|
|
Another advantage is that there is no need for backups at all since every developer has the whole repository.
I have all 4 source control systems on my server (svn, mercurial, git and fossil). Surprisingly, Fossil was the easiest to setup, followed by mercurial and svn. Kiln is pretty cool if you want a mercurial server without the headache of hosting and the command line server configuration. They offer an issue tracker and other useful tools too.
The only thing I miss is a good artifact manager that will fit the branching scheme and really feel integrated in the process.
|
|
|
|
|
|
Thank you for the link. However, I wonder if the major argument (ease of branching) still holds. SVN did get an improvement on that area recently: formerly it was a pain to do partial merges because you had to keep track of what you merged somehow. Now SVN does it for you. It's no longer possible to accidentally apply a merge twice.
|
|
|
|
|
Suppose three devs work on a project. Dev 1 works on something relying on something not yet finished from both devs 2 and 3. But devs 2 and 3 cannot finish what they're working on before dev 1 finishes. Also, there's a central repo to which they patch everything they do once it's stable and finished.
With GIT, you can easily handle this. My experience with TFS is limited, but IIRC, you can also handle it with TFS. But I see no way of handling it with SVN without manually generated patches which get moved around, bypassing SVN.
|
|
|
|
|
In SVN you simply coordinate your work within a branch.
However, in the very few cases of that type I remember over the past 30 years, the solution was not using the VCS, it was: talk to each other. Let one dev do it, or if the combined knowledge is required, let them work on it together. Remember, I was specifically talking of either 1 dev, or a local team.
|
|
|
|
|
Yeah, Git is everywhere now. It's probably a very good idea to have at least some experience with it. A word of caution - it's not the only, or best, DVCS. Mercurial does the same job, and - AND it doesn't suck on Windows.
That said, I'm learning Git because I'm pretty sure I'm going to have to work with it before too long. But there are so many issues with its design and usability, that people just work around and put up with because it's, well Git, and Linus MUST know what he's doing, that it gives me an aneurysm. And that makes it just like VSS doesn't it? Its prevalence is a result of its, well, prevalence?
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
In the face of ambiguity, refuse the temptation to guess.
|
|
|
|
|
I agree. I love Mercurial(a.k.a. Hg), and BitBucket allows you to use both Git and Hg, which is nice. Even better, BitBucket allows you to have private repositories, as well as public, with a free account. GitHub makes you pay for private repos.
VisualSVN works great, and I used it for a few years until recently. But I've been making the transition now to Hg + BitBucket at home, while we use Git + GitHub at work.
Hg tooling in Windows is definitely better that Git tooling, plus Hg lets you use Codeplex, too. The VisualHg plugin for Visual Studio is far better than any Git VS plugin I have seen so far. But, in general, I prefer the command line to any of the graphic interfaces. Having used both, I find Hg easier and more intuitive than Git, but both are good, and fairly similar. You can't go wrong with either.
The world is going to laugh at you anyway, might as well crack the 1st joke!
My code has no bugs, it runs exactly as it was written.
|
|
|
|
|
Like all cool guys that use iPad, iPod, iPod with phone line...
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
"Our heads are round so our thoughts can change direction." ― Francis Picabia
|
|
|
|
|
I've used AnkhSVN for several years now and have had good luck with it. I have also used RocketSVN which I like, both have there Pros and Cons.
|
|
|
|
|
From what I understand, RocketSVN is essentially AnkhSVN and I don't think is being actively developed any longer
info here[^]
|
|
|
|
|
We use VisualSVN server at work as well. As easy as it gets. I don't use AnkhSVN though, since I prefer to do everything with TortoiseSVN via shell extension. A lot of stuff I work on involves resources that live in the folder structure but shouldn't really be included in the project file, so if I'm going to be doing any amount of work from the folders I might as well do all of it.
|
|
|
|
|
Looks like Subversion has a new energetic maintainer, Wandisco.
I use their free UberSVN server (works mostly fine), and svnsync to external hosting, as off-site backup.
TortoiseSVN or Ankh as client.
Also use Mercurial for some projects, but TortoiseHg on Windows still isn't as polished as Tortoise SVN.
Also evaluating Syntevo SmartGit as svn client.
For small personal projects sometimes also use Fossil (especially for cross platform work) - it's amazing ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif) , but no GUI for commits.
-- dd
|
|
|
|
|
|
My choice : Visual SVN Server + Tortoise SVN Client
Zen and the art of software maintenance : rm -rf *
Math is like love : a simple idea but it can get complicated.
|
|
|
|
|
Thanks for sharing.
Wonde Tadesse
MSCS, MCTS
|
|
|
|
|
As someone who has also only recently moved over to source code control please take a look at:
http://nvie.com/posts/a-successful-git-branching-model/[^]
It was my "eureka moment" with git. I picked up the basic usage of git and other systems (such as svn) reasonably quickly, but found myself not able to get my head around when I should be commiting/merging/tagging etc. This article was a fantastic push in the right direction to not only finding out how to use git, but also why I should be using it.
I use git with TortoiseGit alongside VS 2010.
|
|
|
|
|
Thanks! The branching and merging strategy described in the article is what I use at work and what I expect to be able to use with SVN. If it's an arduous task, I'll consider switching to Git. Thanks again!
/ravi
|
|
|
|
|
+5 for the excellent link. That post was a huge help when I was exploring versioning systems myself and has become basis for the model I've been trying to get my department to implement. Very well thought out and clearly explained.
|
|
|
|
|
We have been using SourceGear Vault for years. Integrates very well with Visual Studio, but also has a good stand-alone client.
For a single developer, it's free.
All your source code is in a single SQL server database, so it's easy to backup.
It's not as cool as git, I suppose, but it works and it's reliable.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
