Choosing VCS for Single Developer, Small Projects, Two PC's, Two Locations
-
PIEBALDconsult wrote:
teams of developers
OP wrote:
single developer
:doh:
Yes, I was commenting on the general benefits of smaller files as mentioned in the post to which I was responding.
-
(I couldn't find a better forum for this q, hope it's not out of place) I am a hobbyist just having fun trying to do things that seem interesting, so I have a range of small projects. I work on two laptops at two locations and use a network location at both locations for file storage (network drive at work and a NAS at home) for backup reasons. So, to work on one project I end up shuffling updates back and forth on a USB stick or having to crank up the work laptop at home and connect via VPN just to pull the files. I'd like to be able to use something like a VCS to manage this, recognising (and liking) the extra benefit of being able to rollback to previous versions etc. (fallen foul of this once or twice already). I haven't used SVN, GIT, Bazaar etc. before so I'm not at all familiar (yet) with using them - though I'm happy with the general concept of version control, just not as applied to software development nor doing so via the VCS used in software development. Clearly my preference is for something really simple that does the two jobs I described quickly and easily - (a) make it easy to work on two different devices at two different locations without shuttling USB sticks back and forth and (b) rollbacks. If it has other features then that's great but not if they come at a significant cost in complexity. So, is there anything you could recommend? Or do I need to make some compromises? (Using VS Express so cannot install AddIns but can add menu commands via the External Tools functionality). Thanks, Mike
Hi Mike, Have a look at this tutorial for an SVN setup: http://ilmatte.wordpress.com/2008/04/27/guide-to-versioning-a-visual-studio-solution-with-subversion-tortoisesvn-and-ankhsvn/ I followed the instructions, and it works well for me. I use this setup since several years. The AnkhSVN part is for the VS2010 integration, and might not work with the express edition, so just skip it, although it is really nice to have full VS integration with AnhkSVN, this plugin is really top. Notes: - You don't need to set svn as a windows service, as no other PC will need to connect to your local repository. The tutorial explains how to do that, but you don't need it. - The download links mentioned in the article are somewhat deprecated, but it is easy to find the proper links. hth
-
I use TortiseHG[^] and BitBucket[^] for version control (I have VS 2010 Ultimate, BTW). TortiseHG is kind of finicky to get working, but once you know how to use it, you can get changes pushed online rather quickly.
public class SysAdmin : Employee
{public override void DoWork(IWorkItem workItem) { if (workItem.User.Type == UserType.NoLearn){ throw new NoIWillNotFixYourComputerException(new Luser(workItem.User)); }else{ base.DoWork(workItem); } }}
I also use TortoiseHG (the GUI program for use with Mercurial if you don't want to use the command line). Mercurial is a nice easy version control system that is good for a single developer because it's easy to set up. I use it separately from VS2010 and don't really see a benefit in integrating them. See my previous post[^] for more
-
Since you're using the Express edition of Visual Studio you have no (legal) options at all. There are hacks out there that will get some product here and there to work, but you're violating the license aggreement for Visual Studio Express by doing so. [EDIT] Before everybody else jumps down my throat, I KNOW that there are other solutions to source control that don't integrate with Visual Studio that he can use. This answer was originally intended to handle the case of VS integration ONLY. I should have been more clear. My apologies.
A guide to posting questions on CodeProject[^]
Dave KreskowiakSimply wrong, you just won't be able to integrate source control inside visual studio. Using any of the non-Microsoft SCC systems, the tools can be applied at the command-line. Using tools such as Tortoise SVN give Windows Explorer integration, which can help those with command-line-phobia.
-
peterchen wrote:
can change how you work with source code
I see that as a bad thing.
Please Explain.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
I wonder: the OP specifically asked about single developer projects, and you suggest and even stress the point of GIT being distributed. Why do you think he needs a DVCS? I mean, I do understand the neccessity of push and pull mechanics in distributed development. But for a single developer, where is the advantage over other non-distributed VCS systems, such as creating a working copy with SVN? Or, more to the point, why would it be worth the extra effort of learning a more complicated VCS? I did ask around a lot, and did read up on the various mechanics. Some operations may be faster, but some will also be slower. But for a single developer, the main difference appears to be the learning curve, and everyone, including GIT protagonists, say that it is very steep for GIT.
Fair Question. Three reasons: 1. He's a developer with two locations already 2. It's the future 3. It's not just branching An external site like github can act as both sync point and backup. Now, normally you would start every session with a fetch, and finish it with a push. However, life isn't always so forgiving. Having no internet access to fetch, or having to leave without time to push, you can still work decently and integrate distinct branches through rebasing later. In my myopic view of the world, DVCS are the future. Their only downside is the learning curve. Ubiquitous internet access enables distributed development, and we know that - set up correctly - it's no less efficient than a cubicle mosh pit. DVCS deals with the connection problems. That makes it a decent plus if you join a team or find a coding buddy next town.
On the "It's not just branching" I am walking out on a limp here. My experiences with subversion were back when it was "VSS without the stigma"*. Do I need branches? My attitude went from "branch if you need" to "branch if it helps". The effort (in planning, remembering, considering, merging) becomes trivial. The kicker, though, is that logically you don't work with revisions anymore, but with changes: Branches don't "own" code anymore, they are just containers for different aggregations of functionality. Functionality can can be moved around and regrouped, bug fixes copied to another branch, "Work In Progress" and incomplete ideas are not just "safely stored", but can be kept close to your main branch. Being able to reorder and group commits before they are published solves for me a conflict between "commit offen for easy undo" and "publish a clean, readable history." It also acts as a small "self code review" of my last batch of work. Does a solo developer need a DVCS? No. I freely admit: getting started with git hurt me a lot - luckily I had someone holding my hand (though cp & stackoverflow can give you necessary answers reasonably quickly). However, OP is in a perfect situation to learn tools of the trade - not just what's the minimum necessary to swing by. *) slight exaggeration for artistic purposes. Maybe SVN now allows similar - I honestly can't tell. Even then, the other two poins kind of make it up
-
Simply wrong, you just won't be able to integrate source control inside visual studio. Using any of the non-Microsoft SCC systems, the tools can be applied at the command-line. Using tools such as Tortoise SVN give Windows Explorer integration, which can help those with command-line-phobia.
I know there are other solutions that don't integrate with Visual Studio and I know how this answer was worded would imply that I didn't. Look at the other answer to the OP here[^] and you'd know that.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
But it's not because you can't extend VS that you are unable to use a version control system. You can use one from the command line or use a client like tortoise. You'll learn more about source control too.
I know how the thread started seems like I was saying he couldn't use source control at all. My original reply should have been more clear, but was limited to source control solutions that tried to integrate with VS. My apologies.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
Then explain Subversion, et al.
-
I know how the thread started seems like I was saying he couldn't use source control at all. My original reply should have been more clear, but was limited to source control solutions that tried to integrate with VS. My apologies.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak:thumbsup:
-
I know how the thread started seems like I was saying he couldn't use source control at all. My original reply should have been more clear, but was limited to source control solutions that tried to integrate with VS. My apologies.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak:laugh:
-
Fair Question. Three reasons: 1. He's a developer with two locations already 2. It's the future 3. It's not just branching An external site like github can act as both sync point and backup. Now, normally you would start every session with a fetch, and finish it with a push. However, life isn't always so forgiving. Having no internet access to fetch, or having to leave without time to push, you can still work decently and integrate distinct branches through rebasing later. In my myopic view of the world, DVCS are the future. Their only downside is the learning curve. Ubiquitous internet access enables distributed development, and we know that - set up correctly - it's no less efficient than a cubicle mosh pit. DVCS deals with the connection problems. That makes it a decent plus if you join a team or find a coding buddy next town.
On the "It's not just branching" I am walking out on a limp here. My experiences with subversion were back when it was "VSS without the stigma"*. Do I need branches? My attitude went from "branch if you need" to "branch if it helps". The effort (in planning, remembering, considering, merging) becomes trivial. The kicker, though, is that logically you don't work with revisions anymore, but with changes: Branches don't "own" code anymore, they are just containers for different aggregations of functionality. Functionality can can be moved around and regrouped, bug fixes copied to another branch, "Work In Progress" and incomplete ideas are not just "safely stored", but can be kept close to your main branch. Being able to reorder and group commits before they are published solves for me a conflict between "commit offen for easy undo" and "publish a clean, readable history." It also acts as a small "self code review" of my last batch of work. Does a solo developer need a DVCS? No. I freely admit: getting started with git hurt me a lot - luckily I had someone holding my hand (though cp & stackoverflow can give you necessary answers reasonably quickly). However, OP is in a perfect situation to learn tools of the trade - not just what's the minimum necessary to swing by. *) slight exaggeration for artistic purposes. Maybe SVN now allows similar - I honestly can't tell. Even then, the other two poins kind of make it up
Fair enough.
peterchen wrote:
I am walking out on a limp here.
I suspect you meant 'limb'. Or did you mean 'limping out on a limb'? ;P
-
Yes, I was commenting on the general benefits of smaller files as mentioned in the post to which I was responding.
I totally agree on favoring smaller files. I just wondered about the reference to developer teams. Small files are just as sensible for small teams and single developers as they are for big teams with many developers. I just don't see the correlation you implied.
-
What?! :confused:
X| :rose::cool::suss::~ :| :-O :rolleyes: :omg: :confused::mad:what illa adhu boat ! ok va he he he he :laugh: :) :) :) :-D :-D :) ;) ;P :^) :( :sigh: :doh: :-\ :zzz:
-
I totally agree on favoring smaller files. I just wondered about the reference to developer teams. Small files are just as sensible for small teams and single developers as they are for big teams with many developers. I just don't see the correlation you implied.
Yes, and they are even more important for large teams.
-
OK, slightly confused - does that answer assume I am trying to integrate whatever I end up using with VS Express? If so I think I get that, since it isn't designed to work with extensions then I can imagine the licence restrictions refer to not doing so (not having read all 9x10^6 pages). But...if I was happy to not have IDE integration but just be able, when I've finished a coding session, to push the changed files to an online repository (be it a specific VCS repository or otherwise, like GitHub for example) then what would my options be? Thanks, Mike
Mercurial and Tortoisehg for the win! It is an easier to use equivalent to git. You may also want to take a look at Kiln which is built on Mercurial and adds some gimmicks like a wiki and a ticket system. I went for a clean Mercurial install on my own server, but I came pretty close to using their service instead. Fossil is also pretty cool if you want to want to explore alternatives...
-
Fair enough.
peterchen wrote:
I am walking out on a limp here.
I suspect you meant 'limb'. Or did you mean 'limping out on a limb'? ;P
Stefan_Lang wrote:
I suspect you meant 'limb'. Or did you mean 'limping out on a limb'? ;-P
Thanks for the correction! I wondered which one it would be, but was to lazy to google it. I finally reasoned, we always go out on a limb.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
(I couldn't find a better forum for this q, hope it's not out of place) I am a hobbyist just having fun trying to do things that seem interesting, so I have a range of small projects. I work on two laptops at two locations and use a network location at both locations for file storage (network drive at work and a NAS at home) for backup reasons. So, to work on one project I end up shuffling updates back and forth on a USB stick or having to crank up the work laptop at home and connect via VPN just to pull the files. I'd like to be able to use something like a VCS to manage this, recognising (and liking) the extra benefit of being able to rollback to previous versions etc. (fallen foul of this once or twice already). I haven't used SVN, GIT, Bazaar etc. before so I'm not at all familiar (yet) with using them - though I'm happy with the general concept of version control, just not as applied to software development nor doing so via the VCS used in software development. Clearly my preference is for something really simple that does the two jobs I described quickly and easily - (a) make it easy to work on two different devices at two different locations without shuttling USB sticks back and forth and (b) rollbacks. If it has other features then that's great but not if they come at a significant cost in complexity. So, is there anything you could recommend? Or do I need to make some compromises? (Using VS Express so cannot install AddIns but can add menu commands via the External Tools functionality). Thanks, Mike
For the server: Visual SVN Easy to set up and use. Standard edition is free. For the client: Tortoise SVN One of the best free SVN clients. I use this setup to transfer projects from my office desktop to my laptop. The SVN server resides on a RAID 5 fileserver.