From zero to source code control in 4 minutes
-
As some you know, I write and maintain a number of freeware apps that are used by a fairly large number (thousands) of users. Although I'm meticulous about archiving released and partially complete versions using
.zipfiles (a la poor man's shelvesets), I've always wanted to be able to easily branch my code, view diffs, and track development history in something other than a.txtfile. I've used SVN/Tortoise before but didn't find the Windows Explorer integration seamless. I was considering signing up with a TFS provider so I could enjoy the benefits of robust source code control, similar to what I use at work. (Although TFS 11 Express is free, it only supports VS2011 clients.) However, outsourcing SCC puts your IP in the hands of a 3rd party, which is less than optimal. Renewed research caused me to stumble upon:4 minutes later (including download, installation and configuration times) I was checking out code! The ability to branch, merge, revert to previous versions and easily view diffs on my personal code base is a refreshingly wonderful experience. And backing up the repository is a simple folder copy. And the cost is hard to beat. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
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.
-
As some you know, I write and maintain a number of freeware apps that are used by a fairly large number (thousands) of users. Although I'm meticulous about archiving released and partially complete versions using
.zipfiles (a la poor man's shelvesets), I've always wanted to be able to easily branch my code, view diffs, and track development history in something other than a.txtfile. I've used SVN/Tortoise before but didn't find the Windows Explorer integration seamless. I was considering signing up with a TFS provider so I could enjoy the benefits of robust source code control, similar to what I use at work. (Although TFS 11 Express is free, it only supports VS2011 clients.) However, outsourcing SCC puts your IP in the hands of a 3rd party, which is less than optimal. Renewed research caused me to stumble upon:4 minutes later (including download, installation and configuration times) I was checking out code! The ability to branch, merge, revert to previous versions and easily view diffs on my personal code base is a refreshingly wonderful experience. And backing up the repository is a simple folder copy. And the cost is hard to beat. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
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.
-
As some you know, I write and maintain a number of freeware apps that are used by a fairly large number (thousands) of users. Although I'm meticulous about archiving released and partially complete versions using
.zipfiles (a la poor man's shelvesets), I've always wanted to be able to easily branch my code, view diffs, and track development history in something other than a.txtfile. I've used SVN/Tortoise before but didn't find the Windows Explorer integration seamless. I was considering signing up with a TFS provider so I could enjoy the benefits of robust source code control, similar to what I use at work. (Although TFS 11 Express is free, it only supports VS2011 clients.) However, outsourcing SCC puts your IP in the hands of a 3rd party, which is less than optimal. Renewed research caused me to stumble upon:4 minutes later (including download, installation and configuration times) I was checking out code! The ability to branch, merge, revert to previous versions and easily view diffs on my personal code base is a refreshingly wonderful experience. And backing up the repository is a simple folder copy. And the cost is hard to beat. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
I used AnkhSVN in VS and it made my life a lot easier. However what's made my life even easier was switching to using Mercurial. It is so much better the way you manage different areas and branching. Switch now.
-
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
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
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.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyI'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.
-
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.
-
As some you know, I write and maintain a number of freeware apps that are used by a fairly large number (thousands) of users. Although I'm meticulous about archiving released and partially complete versions using
.zipfiles (a la poor man's shelvesets), I've always wanted to be able to easily branch my code, view diffs, and track development history in something other than a.txtfile. I've used SVN/Tortoise before but didn't find the Windows Explorer integration seamless. I was considering signing up with a TFS provider so I could enjoy the benefits of robust source code control, similar to what I use at work. (Although TFS 11 Express is free, it only supports VS2011 clients.) However, outsourcing SCC puts your IP in the hands of a 3rd party, which is less than optimal. Renewed research caused me to stumble upon:4 minutes later (including download, installation and configuration times) I was checking out code! The ability to branch, merge, revert to previous versions and easily view diffs on my personal code base is a refreshingly wonderful experience. And backing up the repository is a simple folder copy. And the cost is hard to beat. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
You do not even need SVN Server. You can simply access your repositories using file:// protocol: How to use SVN without a server?[^] By the way, you can also integrate SVN with your issue tracker and associate commits with issues which can be very useful in future. Another option is to use Kiln[^] which is free for single developer and integrates with their bug tracker (also free for single user)
Giorgi Dalakishvili #region signature My Articles My Blog #endregion
-
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.
Here is a similar discussion: Are there advantages to using a DVCS for a solo developer?[^]
Giorgi Dalakishvili #region signature My Articles My Blog #endregion
-
As some you know, I write and maintain a number of freeware apps that are used by a fairly large number (thousands) of users. Although I'm meticulous about archiving released and partially complete versions using
.zipfiles (a la poor man's shelvesets), I've always wanted to be able to easily branch my code, view diffs, and track development history in something other than a.txtfile. I've used SVN/Tortoise before but didn't find the Windows Explorer integration seamless. I was considering signing up with a TFS provider so I could enjoy the benefits of robust source code control, similar to what I use at work. (Although TFS 11 Express is free, it only supports VS2011 clients.) However, outsourcing SCC puts your IP in the hands of a 3rd party, which is less than optimal. Renewed research caused me to stumble upon:4 minutes later (including download, installation and configuration times) I was checking out code! The ability to branch, merge, revert to previous versions and easily view diffs on my personal code base is a refreshingly wonderful experience. And backing up the repository is a simple folder copy. And the cost is hard to beat. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Are you using both?
-
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.
-
Here is a similar discussion: Are there advantages to using a DVCS for a solo developer?[^]
Giorgi Dalakishvili #region signature My Articles My Blog #endregion
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.
-
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.
-
Are you using both?
Yes. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
We cool guys all use git now.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyLike 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
-
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.
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.
-
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.
-
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.
-
As some you know, I write and maintain a number of freeware apps that are used by a fairly large number (thousands) of users. Although I'm meticulous about archiving released and partially complete versions using
.zipfiles (a la poor man's shelvesets), I've always wanted to be able to easily branch my code, view diffs, and track development history in something other than a.txtfile. I've used SVN/Tortoise before but didn't find the Windows Explorer integration seamless. I was considering signing up with a TFS provider so I could enjoy the benefits of robust source code control, similar to what I use at work. (Although TFS 11 Express is free, it only supports VS2011 clients.) However, outsourcing SCC puts your IP in the hands of a 3rd party, which is less than optimal. Renewed research caused me to stumble upon:4 minutes later (including download, installation and configuration times) I was checking out code! The ability to branch, merge, revert to previous versions and easily view diffs on my personal code base is a refreshingly wonderful experience. And backing up the repository is a simple folder copy. And the cost is hard to beat. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Have you tried Git. I found it much better than using SVN
Imagination is the one weapon in the war against reality!!! http://aniruddhaloya.blogspot.com
-
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 fucking 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.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
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.
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.