I'm assuming that after a while, many developers come to know/love a particular VCS. What happens if you find yourself on a team using an incompatible system - do you learn the new system and adapt your workflow to the team's, or do you keep your old system, and try to get both working in tandem? It strikes me that this is either a very common strategy, or a serious faux pas.I'm new to software development, so this question is strictly hypothetical for me so far. While my gut tells me that the decentralized structure and branch-happy nature of git/Mercurial would appeal to me more than the very centralized Vault set up my group uses, I do not know nearly enough about working with version control in general yet to prefer any one system to another, so I will be sticking with whatever the team is running for the foreseeable future. But it does lead me to wonder how common it is for developers faced with learning a new VCS to roll a kind of hybrid of both systems - using their preferred system locally to manage what they're working on, and really only using the team wide system to commit/update. This of course leads to other questions - is there a set pattern for working with two systems at once? How do you deal with the fact that your local repo doesn't have access to the full history of the project? Etc...
Do developers on a team ever have a personal version control?
version control;git
The short answer is, it depends on the version control systems in question, your role in the team your working on, and the policy of the company.Some companies have very strict policies about what you can use, and you'll probably be stuck with whatever version control software is the company standard. At other shops you'll find that developers have a bit more flexibility, so if your tool of choice can interoperate well with whatever the standard version control system is, then you can use it.It's important that, if you are using a DVCS to keep a local repository and then pulling/pushing code to a centralized version constrol system, you need to make sure you still commit regularly (keep in mind regularly for something like svn is still less often than with, e.g. git, but make sure you are committing your code fairly frequently- probably daily, at least weekly). You don't want to hoard a ton of changes in your local repository and then make massive commits out of the blue.If you think your preferred VCS is really better for the teams needs than whatever you are currently using, then feel free to mention it and push (lightly) for the team to change. This will be most successful if you push for it before the start of a new release, or at the beginning of a new project. If the team is half-way through a release cycle then realistically anything more than just mentioning off hand that you like a difference VCS is likely to irritate your team members, since switching version control systems mid-project is a really bad idea irrespective of whatever VCS you happen to be using at the time.From personal experience, at my current workplace before I started everything was based on subversion. Since I was hired to start up a new project, I mentioned that I liked git and suggested that we use the new project as a pilot to see if git would be a good fit for the rest of the company. I spent a lot of time mentoring other team members on how to use git, and gradually got them up to speed. In the mean time, when I needed to work on some of the older projects that were still in subversion, I just used svn and didn't make a fuss. By the time the project was done and everyone had had a chance to see the benefits of using a DVCS nobody was opposed to my using git-svn to interact with the old codebase.If I'd started and simply insisted that everyone should switch to git, or insisted on using git locally for everything and complaining about having to interact with svn I would probably have had less success, since it would have come across less as hey, here is this neat thing, and more like I think less of you because you made a poor choice to use that tool.