Do developers on a team ever have a "personal" version control?

Question

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...

Answer 1

The short answer is, it depends on the version control systems in question, your role in the team you're 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 control 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 team's 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".

Answer 2

It is certainly possible to use the new generation of DVCS alongside any other source control system. I do this with Git when I have to.

When working with Subversion, Git has built-in client support which works really well.

I have occasion to use Git alongside other source control systems. You can create a Git repository anywhere, so create one in the working directory of the other source control system. What I do is have a branch that reflects the exact state of the foreign source control system - call that anything, but master works well. Do your own development in some other branch.

To commit your changes back upstream, first switch to the master branch and get the latest upstream changes, committing that to master. Then merge your changes in from your development branch. Hopefully the source control system you're using doesn't require you to specifically mark each file for edit before you change it, but if it does (e.g. Perforce), then you'll have to do that manually. (In the specific case of Perforce, there is git p4 that already does this, but in the general case it won't be pre-written.)

After merging your development into master, commit those changes to the foreign source control system just as you would normally.

With git svn and git p4 (among others I'm sure), these connectors do some or all of the following things for you:

• Map a commit in the remote system to a commit in Git (so you get all the same commit messages and whatnot)
• Automatically check out files for edit (such as p4 edit)
• Commit your changes back to the foreign source control system

I usually recommend the above procedures only for those who are proficient with Git (or whichever DVCS of choice).

Answer 3

It would depend on the situation and how much of subversion is tolerated.

In most cases, you're better off using what the team has decided to use. There's a caveat though - if the team has chosen a reliable version control system (read Git, Mercurial, Subversion etc.) then you shouldn't have a problem using the one chosen by the team in lieu of your own. One must attempt to put aside personal likes and dislikes for the sake of collaboration.

However, there have been times where I've been forced to contend with poor revision control systems and practices. Ever attempted using VSS 6.0 (in 2008)? Via a home-grown web based user interface (that accepted singular file commits taking 5 minutes each)? This would deserve a story of its own, but I've found myself to be far more productive when I replicated the repository onto Subversion and committed the changes back, without breaking the build. I would emphasize on the last part, for it wouldn't be an easy thing to deflect an accusation that you aren't a team player; ensuring that the build doesn't break will add a touch of reliability in your commits.

Answer 4

I run a personal VCS whenever I can't freely or easily branch in the official repository.

I like to commit changes very frequently, so that I can make gross changes without risking my work in progress.

This is a very common practice. DVCS like Git and Mercurial are designed to work in this way.

Answer 5

I have been using a DVCS on top of my company's central VCS for the past year or so, and won't ever look back. Frequent local commits take a lot of mental burden away. During times of build instability in areas I'm not directly working on, I always have a stable baseline to do my personal development and testing against. I have a branch for my long term tasks, but can quickly switch to triage an urgent issue. I can create a new branch to continue working while my previous task is being peer reviewed. The main drawbacks are a little extra complexity when you push or pull from the central VCS, and the need to consciously resist the temptation to go too long between doing so.

My workflow is that my master branch always tracks the central version control, and I do all my work in feature branches, only merging back into master when I'm ready to share my changes. That way all merges with my local changes are done with git, and if someone upstream has made an incompatible change, I can integrate it on my schedule instead of whatever inconvenient time they happened to commit their change.

As far as not having local access to the full project history, most of the time I'm first concerned with what changed since the last time it was working. Then I go to the central version control when I need to know who and why. It doesn't obviate the need to be proficient in the official VCS, but can make a lot of tasks easier.

Answer 6

It is interesting that this question is so old, and other than a new comment, it hasn't seen any activity for 5 years. I suspect that's because git has largely removed the need for a separate local VCS.

Back in the day before distributed VCS was so ubiquitous, it was very common for me to have some variation of what the OP described. Often it was the case that a push to the remote repository was relatively expensive because it would either trigger a build or because you couldn't push anything that you were not confident would work. I'd learned early in my career to commit early and often. I would end up with many intermediate, non-functional commits throughout the day. In those cases I'd use RCS or some other available VCS for my work-in-progress commits, and then check the final result into the "real" system when ready.

Since every place I've been at for years now has used git, this practice has no longer been necessary. The workflow I describe is pretty much built-in to git, so much so that it hasn't occurred to me to try a different system locally for many years.