Related
We have an application at work which is web-based and comes with a bundled web server (Apache tomcat), and is for network monitoring/patch management. It allows for personalisation, all sorts of rules, custom UI design using proprietary components and definition language, and even custom code to fire on events (based on Java).
I am in a team of several developers, each of who will be customising this app to meet various requirements. As it's a server app, not a codebase, what's the best way to setup a dev environment for >1 user?
If there is one single shared VM with this app, I don't know how good source control like TFS would work with this sort of system? I think also, developers working on various parts of the project may even need the same file at the same time (though TFS does do multiple check-outs).
What is the best way to develop against this sort of product? Bare in mind, even with personal VMs and an instance of the app, changes have to be merged to one central instance. Something keeps making me think about how app-virtualisation could help with this?
Thanks
If it is just an instance of Tomcat (even though it was bundled) couldn't you put the whole Tomcat directory and all of its subdirectories under source control? You just need to check in the non-binary parts, so exclude all the .jar, .exe, .tar.gz and .dll files when you check in. That's what I would do, unless I misunderstood your question.
I'm not familiar with the source control software that you mentioned. I have been using SVN (which is free) and TortoiseSVN as a client (also free). Just an option if your software can't support what I've suggested.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Version Control. Getting started…
I am interested in implementing version control for the first time. I am starting to amass custom libraries and would like to know what methods you would recommend for implementing version control on a Windows Vista OS. I also have an Ubuntu server setup. I'm not sure if OS is relevant.
Also, if it is relevant, I primarily use PHP and AS3.
Thanks!
Usually I recommend either GIT or SVN. If you use Windows, SVN may be a better option (I believe the GIT binaries are still in beta for Windows, and the SVN clients are better). I'd also recommend registering for a hosted version system (such as github or beanstalk). Most services offer a free option, and will provide far better data replication than an any individual could create. Lastly, check out a GUI client (such as Tortise SVN) or check for integrations with the IDE you use for editing code.
The tutorial at http://hginit.com/ covers a lot of ground regarding the concepts behind version control, specifically distributed version control. Mercurial is the focus of the tutorial, but the concepts extend to git as well, and to other SCMs to a small degree.
My biggest recommendation is just to start using some version control, right now. It'll change the way you work--honestly.
(full disclosure: I work for Fog Creek, the sponsor of the hginit tutorial)
Last question first: what language you're using doesn't really matter. Even for text documents, Word documents, etc., a source control system will keep track of your versions.
As for which one to use, there are a number of free ones available, that require different levels of administration and expertise. If you're mostly comfortable with Windows programs, SourceGear licenses their Vault product free for single users.
Open source repositories are also not uncommon. Subversion is widely used, but does require a fair amount of server administration expertise.
For an individual, Bazaar in Solo mode is very easy to use. Later if you want a multi-user configuration, other "workflows" are possible.
Go with something like http://beanstalkapp.com
SVN is probably more conceptually easy to understand than Git, and it has more users - hence more tools and easier to find help.
I'd recommend Subversion (SVN) using the Red Bean Subversion book as a guide. Start with Appendix A, then go through chapters 1, 2 at least.
This is my recommendation primarily because it is how I started with version control, not because I think SVN is better than other version control systems.
I agree with Kevin Gessner just start using something and feel the change wash over you!
We use Mercurial. It is fast.
Git, Mercurial, or Bazaar
I am looking for a good source control solution. Here are the requirements:
Must have a GUI or have an available GUI plug-in.
Must be free.
Must work with HTTP.
What source control would you choose?
BACKGROUND
Our .Net development team is part of a large parent company. We're in the process of acquiring VS Team System, however the bureaucracy of a large company moves slowly and it could be months before we have a Team System server up and running. In the meantime, we have a large project that will be outsourced to a vendor in India. In the past, our team's process has been something like this: 1)specify the requirements, 2)let the Indian team create the solution, and 3) receive the solution back from the vendor a month later.
We're looking for a more disciplined approach and Team System is our long term solution, however I'd like to use something right now instead of nothing.
Here are some of my thoughts:
Source Safe is a no-go, because of stability issues.
Ease of use is more important than advanced features, like branching and I'd really, really want it to use a GUI versus command lines.
HTTP access is a must, because the development team will be remote.
Additional Information as a follow up to feedback so far
We need a free solution, not because we can't afford it, but because the company's corporate purchasing policies will delay getting it. Free enables us to install at any time. I suppose that if it were cheap enough, I could pay out of my own pocket, but it would have to be pretty cheap.
Final
Sadly, we did not end up using any of the recommendations. We did finally obtain a TFS license, however we're not expected to have clearance to use the server until next year. In the interim, the offshore team is uploaded zip files onto an ftp server. Ugggghh! Why is it so hard to convince large companies that it's ok to use non-standard solutions (such as GIT) rather than wait months (or years) as they dither on trying to decide whether or not a purchase (in this case TFS) is worth it.
I recommend Subversion and TortoiseSVN. Even the documentation for Subversion is free.
Edited to add:
I also strongly recommend VisualSVN Server to setup your SVN repository. The setup was a snap and its been so trouble free I had to go look to see what it was called because I haven't had to touch it once since the initial set-up.
Think about a distributed system: darcs, git, or mercurial. They all have their adherents, but operationally they're much similar. darcs can take a long time to build, because it's written in Haskell, and you end up needing to build Haskell first. Mercurial is python based, easy to hack with and extend. And of course git is what's used for Linux, very widely available, lots of tools.
Subversion is, I think, pretty much the baseline of modern SCM; it would be a good choice too, but it does force you into having a fixed central server; either you, or your Indian collegues, will have to check out and commit over a long pipe.
Subversion (SVN) is obviously a popular choice. It's also quite commonly used now (Google Code, Sourceforge, etc.) so there should be lots of documentation out there about its use. Git is a good choice too, but the lack of GUI interfaces available makes it not fit your requirements so well.
I'm assuming since you're using .NET you're developing in a Windows environment primarily. Check out VisualSVN products. They make a great (FREE) Server product for actually running a full fledged svn server in a windows environment (it supports SSL, group/user authentication including Active Directory support).
They also offer a Visual Studio plugin, although it is not free (although quite reasonable at $49/developer). AnkhSvn is another Visual Studio client plugin option. It's not quite as great, but it is free.
http://www.visualsvn.com/server/ - Free Windows SVN Server
http://www.visualsvn.com/visualsvn/ - Visual Studio Client Plugin
http://ankhsvn.open.collab.net/ - Free Visual Studio Client Plugin
So, I think Subversion using VisualSVN's product offerings are going to give you the best windows/gui integration at a very reasonable price.
SVN sucks quite badly over HTTP in my experience. You will want to pull your hair out if your repo is of any significant size especially with a Trans-Atlantic round trip stuffed in there. Personally I'd go with Mercurial.
Google has recently done some research on Git versus Mercurial. The largest advantage that Mercurial had was that it played extremely well with HTTP.
TortoiseHg, while not quite as mature as TortoiseSVN, is a pretty solid Windows GUI. Although you mentioned you're not very interested in branching and merging, these are common activities in all DVCS. Fortunately because they are common, they are well supported in the UI and relatively painless activities overall.
Check out Subversion: http://subversion.tigris.org/
Has GUI plugin as well VS .NET. http://tortoisesvn.tigris.org/ http://ankhsvn.open.collab.net/
All open source & free.
My recomendation is Subversion + TortoiseSVN (for Explorer integration) + AnkhSVN (integration with Visual Studio).
I think you shouldn't use any of the distributet version control systems because after that you will have to get back to centralized one which could be painful.
As mentioned SVN and Tortoise are the way to go.
I'd also get a license for visual SVN (http://www.visualsvn.com/) it's not free but it is really good, it uses Tortoise svn and gives you it's features in the IDE.
Team Foundation Server is quite easy to use and is easy to get started with coming from a source safe background (shares common terminology for commands). However with part of the development being in India, they may be more knowledgeable about Subversion.
If you use Subversion, i would look at VisualSVN. It's fantastic, simple to use, and quick to set up (TFS is a bit complicated to set up). VisualSVN offers an IDE plug-in ($50) and a server counterpart that bootstraps Subversion for windows machines (Free)
Mercurial is great and really easy.
Give Mercurial a shot. BitBucket has free accounts you can play around with. I've written more about why I use it here.
Have you tried SVN and using TortoiseSVN for the Shell Extension?
I second SVN and TortoiseSVN.
I moved from CVS and WinCVS and I am very happy with this setup.
I would recommend the source control where most of your team members have the most experience or where you have someone on your team who is an expert for.
In my opinion besides the endless "git is better than Subversion is better than CVS"-discussion I don't think the differences between them is what matters.
It's more important to have someone who really knows how to use whichever system you decide to use.
Setting up Subversion for .Net development has gotten easier. You could start by installing Visual SVN Server. This will install Subversion Server on a windows machine, will work you through setting up your repository, authentication, etc.
Then for Visual Studio integration with Subversion you can try VisualSVN, it's not free but well worth the license. But if your budget don't allow it, Ankhsvn also works fine, I use it everyday.
I had to make a similar decision several months back. I liked SVN a lot, but the lack of GUI for the administration was a big issue for my team. TFS was ideal, but very expensive.
We decided to meet halfway and license SourceGear Vault. It doesn't meet your requirement of "free," unfortunately. Although I did find its comparison with SVN to be interesting.
If you're certain you're going to Team System, then I believe there's a 180-day trial you can use. That way, you son't have to switch.
Have you tried unfuddle (http://unfuddle.com/). Fulfills all your requirements.
Another vote for SVN.
For a lightweight SVN server on windows look at sliksvn. It doesn't do http source browsing, but is a much smaller and easier setup than apache based servers for small groups.
We are considering using ClearCase Multisite to enable the offshore development team. The other option is the ClearCase Remote Client using the local (onshore) ClearCase installation. Has anyone had experiences using Multisite? Is the synchronization and management hassle worth offshore being able to use the fat client?
That is a good question. I belive it is worth using multisite so long as you can figure out the mastership of elements. If an element is mastered at site A you can't edit it at site B until you have transfered the mastership. So if each site is working on the same pieces of code then multisite is going to be more trouble than it is worth, if the coverage is disjoint then multisite is a good call. Clearcase is very chatty on the network and keeping as much local as possible is a good idea.
I agree with stimms. Actually, unless you have a massive concurrent development on the same set of files, multisite is quite heavy to setup and maintain...
And if the coverage is disjoint, ... actually we have switched to CRC (but we are with CC7.0.1 here, CRC in 6.0 was not advanced enough). That means you have a good connection to allow your user to connect to the web server that represents CRC and that will access your vobs for them.
Your remote clients will either use a "semi-fat" client (the eclipse RCP ClearCase client talking to your CRC) or a web interface, for setting up their snapshot views.
The other point that drove us away from Multisite is the licensing system: you can not convert a vob into a 'multisite-compliant' one without using (more expensive) multisite licenses, even for your local users...
So if you want to use only multi-site licenses for your remote users, you have to isolate your data into a multi-site vob, and then replicate those data into a normal vob!
All in all, I believe Multisite is not the only answer to offshore development team.
BUT, that being said, one strong force of the Multisite mechanism is its ability to synchronize itself from delta coming from various sources:
regular reception of packages
files
even a CD burned with the latest delta can do it!
That means, if your connexion is not always up with the remote site, Multisite can be a valid option.
One of the really big differences between Multisite and CCRC is the fact that you can only use snapshot views (but actually called webviews) with CCRC whereas Multisite can do both snapshot and dynamic views.
As the previous poster stated, there are also monetary and administration costs to consider.
Without more information about the size of the offshore team, what they are likely to develop, how long you are going to be using the solution for, the size of the business, the administration experience and time of your ClearCase staff...well, it'd be tricky to answer this accurately.
MultiSite is a great product, and truly enables remote sites in a way CCRC does not. It also serves as a backup replica for your VOBs. There are many things to consider, but don't let the complexity of MultiSite turn you away... I suggest you look into CM/InSync to automate MultiSite into a hands-free setup.
The CCRC client is OK, stil lackluster in comparison to native dynamic views. It very much depends on your requirements and needs.
d.
I've been programming for 10+ years now for the same employer and only source code control we've ever used is VSS. (Sorry - That's what they had when I started). There's only ever been a few of us; two right now and we usually work alone, so VSS has worked ok for us. So, I have two questions: 1) Should we switch to something else like subversion, git, TFS, etc what exactly and why (please)? 2) Am I beyond all hope and destined to eternal damnation because VSS has corrupted me (as Jeff says) ?
Wow - thanks for all the great responses!
It sounds like I should clearify a few things. We are a MS shop (Gold parntner) and we mostly do VB, ASP.NET, SQL Server, sharepoint & Biztalk work. I have CS degree so I've done x86 assembly C, C++ on DEC Unix and Slackware Linux in a "time out of mind" ...
My concern with VSS is that now I'm working over a VPN a lot more and VSS's performance sux and I'm afraid that our 10+ y/o version 5 VSS database is going to get hoosed...
There's the LAN service that's supposed to speed things up, but Ive never used it and I'm not sure it helps with corruption - has anyone used the VSS LAN service? (new with VSS 2005)
I'd probably go with Subversion, if I were you. I'm a total Git fanatic at this point, but Subversion certainly has some advantages:
simplicity
abundance of interoperable tools
active and supportive community
portable
Has really nice Windows shell integration
integrates with visual studio (I think - but surely through a third party)
Git has many, many other advantages, but the above tend to be the ones people care about when asking general questions like the above.
Edit: the company I now work for is using VisualSVN server, which is free. It makes setting up a Subversion repository on a Windows server stupid simple, and on the client we're using TortoiseSVN (for shell integration) and AnkhSVN for Visual Studio support. It's quite good, and should be fairly easy for even VSS users to pick up.
Latter-day Edit: So....nearly eight years later, I would never recommend Subversion to anyone for any reason. I don't really recant, per se, because I think my advice was valid at the time. However, in 2016, Subversion retains almost none of the advantages it used to have over Git. The tooling for Git is superior to (and much more diverse) what it once was, and in particular, there's GitHub and other good Git hosting providers (BitBucket, Beanstalk, Visual Studio Online, just off the top of my head). Visual Studio now has Git support out-of-the-box, and it's actually pretty good. There are even PowerShell modules to give a more native Windows experience to denizens of the console. Git is even easier to set up and use than Subversion and doesn't require a server component. Git has become as ubiquitous as any single tool can be, and you really would only be cheating yourself to not use it (unless you just really want to use something not-Git). Don't misunderstand - this isn't me hating on Subversion, but rather me recognizing that it's a tool from another time, rather like a straight razor for shaving.
Looks like SubVersion is the winner here. I'd do yourself a favor and use VisualSVN Server. It's free and will save you a bunch of installation headaches.
If you're used to the way VSS works, check out (no pun intended) Sourcegear's vault. It's an excellent way to migrate away from VSS as it comes with IDE integration and supports check out / check in, but when you're ready and feel comfortable you can also move to the edit update commit style of programming found in SVN.
It's free for single developers, runs on IIS and is built on .net so it should be a fairly familiar stack for you to switch to.
Whatever you do, don't change for the sake of changing.
If it's working for you and you're not having problems with it, I don't see any reason to switch.
For what it's worth, Perforce is a potential option if you truly stick to 1 or 2 users. Current perforce docs says you have have 2 users and 5 clients without having to start purchasing licenses.
You might have reasons to switch to perforce depending on your workflow and if you have need of branching the way perforce does it. Not being overly familar with some the other products mentioned here, I can't tell you how perforce compares in the feature department for things like branching, etc.
It is speedy, and it's been rock solid for us (300+ developers on a 10+ year old codebase). We store several T of info and it's been quite responsive. With a small number of users, I doubt that you'd experience many performance troubles assuming you had good hardware for your server.
Having used VSS before, I believe that you can get so many benefits out of a better SCM system that switching should be considered regardless of whether you have corruption or not. Branching alone might be worth it for you. A true client/server model, better interfaces (programmatically and command line) are a couple of other things that could really help just improve your workflow and help somewhat with productivity.
In summary, my view of Perforce is:
It's fast and quite reliable
Plenty of cross platform client tools (windows, unix, mac, etc)
it's free for 2 users and 5 clients
Integrates into developer studio (and other tools)
Has a powerful branching system (that might or might not be right for you).
Has several scriptable interfaces (python, perl, ruby, C++)
Certainly YMMV -- I only offer this alternative up as something that might be worthwhile looking into.
I've recently started using Mercurial for some of my work. It's a distributed system like Git but seems easier to use and seems far better supported on Windows, the latter of which was crucial for me.
With distributed source code control every user has a complete local copy of the repository. If you're the only person working on a project, as you say you often are, this can simplify things a lot since you just create your own repository and do all your commits etc. locally. If you want to bring on other developers later you can just push the full contents of your repository - current versions and all history - to another system, either on a shared server or directly on to another users' workstation.
If you're working only with a local repository remember you'll need a also backup solution as there isn't a copy of all your code on a shared server.
I think that Mercurial has lots of other advantages over Subversion, but it does have a big downside which has already been mentioned as a plus point of Subversion: there a lots of third party tools and integrations for Subversion. As Mercurial hasn't been around nearly as ong the choice is much less. On Windows it seems that you either have to use the command line (my choice) or the TortoiseHg Windows Explorer integration.
VSS is horrible. I may be channelling Spolsky (not sure if he's said this), but using VSS is actually worse than not using source control at all. Despite its name, it isn't safe. It creates the illusion of safety without providing it.
Without VSS, you'd probably be making regular backups of your code. With VSS, you'll think, "Mehh, it's already under source control. Why bother backing up?" Great until it corrupts your entire codebase and you lose everything. (This, incidentally, happened at a company I worked at.)
Get rid of VSS as soon as you can and switch to a real source control solution.
Don't worry about VSS corrupting you, worry about VSS corrupting your data. It does not have a good track record in that department.
Back up frequently if you do not switch to a different version control system. Backups should be happening daily even with other SCMs, but it's doubly important with VSS.
I like using Subversion for my personal projects. I could go down the list of features and pretend like it brings a lot to the table that other source control systems don't, but there's tons of good ones out there and the right choices is really a matter of style. If you check in after each small change (i.e. one checkin per function change), then many people can work on the same source file with very low risk of merge conflicts in practically anything but VSS (I haven't used VSS in years but from what I remember only one person at a time can work on a file.) If this isn't ever going to happen to you, I feel like the best course of action is to use what you know. VSS is better than no source control at all, but it feels restrictive to me these days.
I don't think you're beyond hope because you're asking if it would be better to switch; you're beyond hope when the answer is obvious and you ignore the evidence.
Even if you don't change source control systems, you ought to pick one like SVN or git and spend a few weeks reading about it and making a small project using it; it always helps to sharpen the saw.
I don't agree with the people that say that if you don't have problems you'd better not switch.
I think that SCM is some of the disciplines a good developer should know well, and frankly, even if you master VSS you are just experimenting a small fraction of the advantages a good SCM tool and SCM strategy can do for you and for your team.
Obviously evaluate and test the alternatives first in a non-production environment.
At work we use subversion with TortoiseSVN - works very nicely but it is philosophically different to VSS (not really a problem if there's just you but worth being aware of). I really like the fact that the whole repository has a revision number.
Given a free choice I'd've probably gone with vault but at the time I had zero budget.
I'm looking at things for personal use. There are reasons to use subversion and reasons to use something completely different. The alternatives I'm considering are Vault (as before, free for single use) and Bazaar. GIT I've had to dismiss as I am, unashamedly, a Windows person and right now GIT just isn't.
The distributed nature of GIT and the option of private/temporary checkins (assuming I've understood what I've read) is attractive - hence my looking at Bazaar.
Update: I did some more digging and playing and I actually went for Mercurial for personal use, integrated install with TortoiseHg makes things very simple and it seems to be well regarded. I'm still trying to work out how to force an automagic mirror of commits to a server and there appear to be some minor limitations to the ignore function but its doing the job nicely so far...
Murph
I'd say stick with what works for you. Unless you are having issues with VSS, why switch? Subversion is swell, though a little sticky to begin using it. TFS is far better than VSS, though it is fairly expensive for such a small team. I have not used git so I can't really speak to it.
i used vss for years until switching to svn about two years ago. my biggest complaints about vss were the poor network performance (that problem may be solved now) and the pessimistic locking of files. svn solved both those, is easy to set up (i use collabnet server and tortoisesvn client, although there are two good visual studio plugins: visualsvn - commercial, and ankhsvn - open source), easy to use and administer, and well documented.
it's tempting to say "if it's not broken then don't fix it" but you would get to learn a more modern source control tool and, perhaps more importantly, new ways of using source control (e.g. more frequent branching and merging) that the new tool would support.
If you only have 2 people, and you mostly work independantly, git is going to give you a lot more flexibility, power, and be far and away the fastest to work with.
It is however a pain in the backside to use. Using VSS you're obviously programming for windows - if you're doing Win32 API stuff in C then git will be a learning curve but will be quite interesting.
If the depths of your knowledge however only extend to ASP and Visual Basic, just use subversion. Walk before you can run.
** I'm not trying to say if you only know VB you're dumb or anything like that, but that git can be very finicky and picky to use (if you've used the WinAPI in C you know all about picky and finicky), and you may want a more gradual introduction to SCM than git provides
If you are a one man show and strictly a Microsoft shop, then SourceGear Vault is definitely a prime candidate for switching too.
Features:
Free for Single User, great for you
It uses SQL Server for it's backend, therefore data reliability is huge
It has atomic check-ins, all files checked-in at the same time are arranged in a group and are called a changeset.
VisualStudio integration.
Has a tool for importing from SourceSafe, therefore you can keep your history
The client communicates with the server over HTTP, therefore accessing the source outside the office remotely can be setup very easily and performs well, because they only transfer the deltas of the changes being submitted and received. You can use SSL to secure the connection.
I would definately consider this as an option.
If you want a full Life Cycle in one package then you probably want want to look at Visual Studio Team System. It does require a server, but you can get a "Action Pack" from MS that includes all the licencies that you need for "Team Foundation Server Workgroup Edition" from the Partner centre.
With this you will get Bug, Risk and Issue tracking as well as many other features :)
Source Control
Work Item Tracking (Requirements, Bugs, Issues, Risks and Tasks)
Reporting on your project data (Work Item Tracking, Build, Checkins and more in one qube)
Code Analysis
Unit Testing
Load Testing
Performance Analysis
Automated Build