I am jumping off a laptop as my primary development machine and moving to an iMac. I plan to maintain an older laptop for development use on business trips and other working travels, as well as occasional coffee shop visits.
Would love to hear any protips out there for maintaing two dev environments while minimizing the necessary fiddling. Details would be great! I generally work with Ruby, Rails, MySQL, git, and numerous Ruby gems.
Thanks in advance for all ideas you can share!
I've found that using something like MacPorts can the ease the pain of maintaining n different systems. And not only maintaining them, but keeping the environments fairly close (same versions of same packages).
And if you can't guarantee access to your VCS, then you can do something like host a "local" VCS on your iMac that you can then commit to from your laptop.
A distribute VCS like Git is perfect for this, even if you use a different VCS for you main code on the Mac.
That way you can use the distributed features to commit code to your laptop and sync everything up easily both before you leave, and when you get home.
It sounds like you want to make sure the code in the 2 environments is in synch. Create a sandbox from your version control system and keep everything in the VCS. If you can't guarantee access to your VCS server, keep the latest on a USB stick and carry it with you.
Related
Imagine you're going to manage a number of servers with a number of different services that's used by a number of people. Now say you want to reconfigure or replace some software on one of those servers. Obviously you don't want to work on servers that are in production.
If this was a code change, as a developer, I would make the change on my local development machine, test it locally and commit the change to a version control system. The changes could then be deployed in a staging environment, tested further and finally deployed in a production environment. It would also be easy for me to roll back, if necessary.
Generally, or specifically, how do you achieve this in system administration?
(The first thing that comes to mind is to use virtual machines and put virtual machine images in version control, but I'm sure there is a lot of literature and clever solutions I'm not presently aware of.)
Use chef or puppet to enforce machine configurations, and place their cookbooks and recipes under version control. Yes vms would make things easier but even physical server provioning can be controlled by kickstart or preeseed which can again be version controlled.
I am experimenting with different open source projects just to see which one I can work with since I am a beginner. Of course, many projects have different dependencies and programs that you must install. I want to keep things organized and I don't want to pollute my main windows account, since I use this machine for everyday computing also.
Will creating a seperate windows account on my computer help separate the dependencies for the projects? Are there any better alternatives (other than using virtual machines)?
Thanks
Although you mentioned other than them, but virtual machines are actually the best option if you're planning on working with a lot of different projects and you don't want to pollute your environment too much. If you build them right, you can have a baseline VM that is simple to revert back to if you want to start from scratch because the environment got too polluted.
The problem with only using a separate account is that many installable tools and libraries means they're still going to be made available for all users on the machine, so it doesn't keep things cleaned up. For example, if Visual Studio tools typically apply to all users on the machine. COM dependencies aren't user specific. Some things install Windows Services that need to be running most of the time, but you don't use unless you're developing for them (like SQL Server Reporting Services).
How about installing many kinds of operation system?
If you have enough money, you can buy a computer only for experiment
Virtual machines is definitely the way to go - most non-trivial software modifies more than HKEY_CURRENT_USER machine state. If you don't want full-blown virtual machines (but oh, they're sweet, especially the ones supporting state snapshots!) you could look at something like sandboxie.
So I've decided it's probably best if I get some Source Control solution going to keep my hard work safe, and to help eradicate bugs between versions.
I'm familiar with SVN as far as checking stuff out, but I have NFI about the committing side of things.
What is a good Source Control solution, keeping in mind that I develop in Visual Studio on Windows? Should I get a hosted solution, or host it myself on my own server (running Windows Server '03)
I'd suggest using git and get Git Extensions for better Windows integration.
If you're just getting started and are looking to self-host, I suggest VisualSVN. It's a lightweight, extremely easy-to-use SVN server, and free. I've used it for small projects at work and home. It includes security, with folder- and file-level ACLs based on local or Windows users.
You may decide later to move to more powerful servers or an externally-hosted solution; you can just dump the repository from VisualSVN with the standard svnadmin tools and load it into something else very easily.
For the client side of things, I use TortoiseSVN and love it, and I understand Ankh has gotten better since last I used it.
Use git.
One workflow that git does really well:
Have an idea for some feature you want to implement
Create a new branch for that feature
Write code, commit like crazy
When you're done implementing, squeeze all the crazy commits into one big patch
Commit that patch against your main branch
Delete the for-that-one-feature branch.
This is wonderful to have. You can have multiple parallel branches for this, and it's really easy.
As an additional feature, if your project goes public and you use git, people who check out your code will have an easy time making their own changes to (their copy of) your code, version-controlled and all, and it'll easy to track upstream at the same time.
If not git, try some other distributed source control system and see if it does good branching and local commits as well.
We are a small team (seven people) we have been using a hosted solution (hosted-projects.com) for more than one year. It's cheap and has worked very well for us. We use tortoiseSVN for the clients.
The main advantages of a hosted solution are:
no need to worry about server setup and maintenance
remote hosting means we have a complete and up to date backup of our code on a remote location
very fast
I recently did a team development thing and we just hosted subversion on one of our workstations and it worked... passably. We used visual svn on the server, and tortoiseSVN on all of the clients (and I occasionally connected my macbook using Versions, SVNX, or the command line). Merging is the really hard part... we had a lot of trouble with that (resolved, once again, with some command line skill). I also set up my own subversion server on my linux workstation for personal use, which worked better (merges were smoother, only one developer). Overall, it has been fairly easy and merging is probably the largest problem you'll face.
If your new to source code then I would recommend you read Eric Sink's series on Source Control. It doesn't really cover distributed source control but it's still a very good primer.
I personally use Perforce. They allow up to two uses for free for home and small business use. It is a little expensive compared to others but there is reasons why companies like Google and Symantec use it. It has ok to good Visual Studio support.
I really like hosted solution because often comes with other tools like trac to manage your project timeline and bugs control.
I recommend projectlocker or codespaces
I have secured the budget to upgrade the individual workstations and latops. While newer, bigger screens were welcomed with enthusiasm, the thought of re-installation tools and settings caused most of them to blanch and I got one "Do I really have to?".
How much downtime do you usually have when you move to a new machine?
Do you employ tools or script to set up your dev environment, tools, db's, debuggers etc.specifically for a windows environment?
Is there a standard image that you keep and then let devs move in and tweak the machine as necessary?
My company essentially virtualized in order to stop wasting so much time with upgrades/system failures.
Whenever a desktop/laptop failed, we'd have to spend a better part of a day fixing it and reloading the software.
So, we went out, bought iMacs for everyone and loaded Parallels (a VMware like product for OSX) on them. Then we made a standard dev image for everyone, and just copied it to everyone's machines.
Essentially, if anyone's configuration got messed, we just loaded in a fresh image and kept on truckin'. Saved a lot of time.
Some additional benefits:
When new software is out, we just make a new image and distribute it. Not OS re-installs or anything like that.
If hardware changes, doesn't matter, just move the image.
You can run multiple os's concurrently for testing
You can take "snapshots" in your current image and revert if you really messed something up.
Multiple builds on the same machine...since you can run multiple os's.
Surprisingly the overhead of a virtualized system is quite low.
We only run the software on a real machine for performance tuning/testing purposes.
One day is generally enough for upgrades. I do keep digital copies of VS.NET so much easier to install.
When it comes to other tools generally it's just better to go to websites and install the latest version.
Also it's a good idea to install tools whenever you need instead of trying to install everything at the same time.
The last time I upgraded to a new machine, I think it took about 4 hours to get most of the necessary tools reinstalled. Over time, I've had to re-install quite a few more tools, but I think it's worth it.
If you can get a ghost/image of the default tool set (Visual Studio 2003-2008, Eclipse, NetBeans, or whatever you're using), and all the major service packs, that would help a lot with the initial setup.
I think the downtime is definitely worth it, a new, faster machine will make anyone more productive.
You can have 0 downtime by having both machines available. You will not have as much productivity.
This depends on the number of tools needed by the development team. Tools such as Rational Software Architect can take hours to install on their own. The exercise of having the developers list the applications they need before moving in can help you optimize strategies to deploy effectively. Both machines should be available for a fixed period of time and having them available can allow develoers to both work and kick of long running installs at the same time.
Creating a standard image based on the list provided to you can improve efficiency. Having the relvant software on a share could also let them cherry pick as needed and give the development team the feeling that they can go back as necessary.
Tools to assist in catpuring user settings exist. I have only ever had experience with Doctor Mover. If you have 100 or more developers to move it may be worth the cost. I can't complain too much but it wasn't perfect.
I have never had a problem with just getting a list of all the software a particular users uses. In fact I have never found the base install to be much of an issue. The parts I tend to spend the most time on are re-configuring all of the users custom settings (very common with developers I find). This is where it is very valuable to have the old machine around for awhile so that the user can at a minimum remote-desktop to it and see how they have things set up.
Depending on how your team works, I would highly recommend having every user receiving a new computer get the latest source tree from your source control repository rather than by copying entire directories. And, I would also recommend doing that before actually sending the old workstation elsewhere or even disconnecting it.
One of the great things about tools like CVS and SVN is that it is quite easy for developers to end up with an unofficial "personal branch" from things that are not properly checked in, merged, etc.
While it will cost time to deal with the shift if things are not properly synchronized, it is an invaluable opportunities to catch those things before they come to haunt you later.
Assuming that I'm starting a new web project at home using Visual Studio, which version control system, viz. Git or Subversion will be better to use? Which one will have the least setup complexity?
Since this is for your own personal playing around, my question is simple: Do you know Subversion or Git already?
If you know SVN - use Git.
If you know Git - use SVN.
If you don't know either - use SVN. It's a better introduction.
I'd go with Git. It's not that bad getting up to speed on the basics (there are now a ton of good resources, including learn.github.com) and it'll pay off in spades. And I've been using it on Vista with no probs.
Subversion is far more Windows-friendly in my experience and also more immediately useful for the solo developer.
Another possibility is Perforce, which is slightly less Windows-friendly, but full featured and fairly easy to use, not to mention free for up to two users.
Git is a distributed source control setup and as you are the only user I can't imagine that you would benefit much from its features. Subversion is (in my opinion) easier to set up so I would recommend you go with it.
If you are working alone and want some kind of version control easy to use, then use Subversion.It works great on Windows, setting up the repository is one right click in an empty with Tortoise SVN. Ankh SVN provides a very good integration with Visual Studio - almost on par with TFS provided you use VS 2005 or more recent.
On the other hand, Git is much more promising than SVN. I'll check it during this year, but third party tools are not on par yet.
I'd go with Mercurial instead. It's supposed to be similar to Git (which I never could get running because of the Windows issue) and is really easy to setup in Windows & very nice for "personal" version control systems.
Which one you decide to use depends a lot on what your needs are now and going forward. Git has a very nice community built a round it with GitHub which is great for sharing code and projects. SVN is pretty simple to setup and get going, but in large teams Git has it beat hands down with it's branching and merging. This is ideal in cases where you have multiple people working on the same project, either in an office setting or an OSS sense where the team is spread out.
If all you need is something quick and simple to setup and get going so you can start your project, SVN should be fine. SVN is also integrated into many editors and IDE's as well as many bug tracking and continuous integration systems.
If you plan on having a team, or already do, Git is worth looking at for its branching and merging setup. Git however, due largely to still being kind of young, doesn't have nearly as much support available
If you want Visual Studio integration there is no question. Only Subversion has Visual Studio integrations (AnkhSVN, VisualSVN and several scripts that allow access to TortoiseSVN).
One of the most important reasons that Subversion has such a large amount of tools written for it is that it was designed as a stable library for use by multiple clients.
It's unlikely that Git gets the same level of integration in Visual Studio before git support is available as some kind of reusable library. (There are plans for a libgit2 that could make this a reality).
Let's my ride-in on your question and ask:
Does Git work on Windows?
Does it have something that's equivalent to Tortoise? (otherwise I don't see how it could compete with SVN in terms of ease-of-use)
On a side note: If it's really a one man home project, you don't really need any source control tool. Just put your project in a DropBox folder and you're done (auto-commits, infinite revisions, undelete).
Unless you really think you're going to need tags and branches and stuff. But for personal home projects... do ya?
You can make your own opinion after reading this : http://whygitisbetterthanx.com
Git................................(these dots are there because SO wont accept a 3 lettered answered).
A great answer to this question was recenting written about by Jack Repenning here:
If you have compelling requirements for a single, certain, master copy of your work, use Subversion. You can do this with Git, so long as there are no slip-ups. But you can’t do anything else with Subversion (slip-ups or no), and “compelling requirements” like Sarbanes-Oxley are happier with guarantees than possibilities.
If you plan to maintain parallel, largely shared but permanently somewhat different lines of the same product, use Git. One common example: perhaps you have a large product that you customize for each customer. The customizations are permanent, and generally not shared among code lines, but most of the code is common to all. Git was designed for just this case (in Git terms, local customizations to the common core, and occasional feature or bug-fix contributions back up-tree)
Neither of those? Take your pick, you should be fine with either tool.*
Full Blog Post here: http://blog.codesion.com/post/15692788883/subversion-or-git-decisions-decisions
With SVN you will have to set up a server, create a repository there, check out the (empty) repository, add your files, and then commit.
With Git, all you need is git init in your project's root directory. Then you can add and commit files as you see fit.
There's not really any idea in setting up a Subversion server, since you're the only one working on the source. Contrary to what many people think, solo projects is a perfect match for distributed version control tools. It's also very easy to grow your project later on.
In my experience, Subversion is easier to "grok", but Git is faster and easier to engage in software development best practices. As a former CVS user, Subversion made immediate sense to me when I started using it. Git took some study and I still have to refer to the manual from time to time, but I love how easy it is to branch and merge code when I've got to maintain a release process.
If you are already familiar with CVS and just need something to keep your history and diffs, Subversion will be easier to get started with. If you are new to version control, the tide is shifting toward DVCS in general and Git in particular, so you may get more mileage out of that in general.
I do recommend you look at a hosted provider so you don't have to worry about setting up a Subversion server or so you can have a backup location for your Git data. You can Google for "subversion hosting" or "git hosting" to see the premier providers in the space.
If you plan to take your project along on an USB stick, use Subversion. Windows XP it really, really, really bad at caching lots of small files on an USB stick. Git writes many small files for commit operations and that takes ages on Windows.
[EDIT] The problem with Windows XP and files on an USB stick is caching (or the lack thereof). To prevent data loss, XP will always write files synchonously on an USB stick (so any write will come back only after the FS has reported that all blocks have been written to the stick). Add that to the fact that USB sticks are slow when handling small files (they have a lot of overhead initializing their wear level management) which leads to very poor performance for any kind of application which writes lots of small files.
[EDIT2] If you put a SVN checkout on the USB stick, you will also have a lot of small files (especially in the .svn directories). So the solution in this case is to put the Subversion repository (the "server") on the USB drive. The repository uses only a bunch of big files (if you use the database option instead of the file based one: svnadmin create --fs-type bdb). This avoids the "many little files problem". There is no way to achieve the same thing with current versions of Git.