12

I work as a Mercurial consultant and I've found that it's not too hard to explain DVCS to new users, provided that you don't confuse them. So what I do is: Emphasize the core principles. The history model in Mercurial is actually very clean and simple. In particular, I find that branches are modeled better in Mercurial than in, say, Subversion. Talk with ...


11

This is an interesting question. Before the analysis, I'll say that bandwidth savings shouldn't be the reason you switch to a DVCS. However, a related point is the load on the server and that will naturally go down with a DVCS: people are simply not using the server as often. When they use it, they use it for "simple" things like push/pull. Heavy-duty ...


7

I have used perforce "in anger" i.e. on a project; it is very good for situations in which your source tree is extremely large- dozens to hundreds of gigabytes of source code in multiple languages, binaries (which should not have been checked in), etc. Similar to subversion, it lets you check out only a part of a repository at a time. Unlike subversion, it ...


7

If your CVCS is slowing you down (would be he corollary from your question) then your workflow is broken not your VCS. Edit: (text to long for comment) I think you are missing the point. If your procedures regarding VCS's can slow you down only if they make up a significant amount of your development time. This would be true if either the VCS or your ...


6

The best way is to do a pilot with one existing team and record what the issues are. In my experience, the biggest obstacle to using a DVCS in an enterprise is the lack of structure. A DVCS is more of an SCM framework than a full solution. You have to add a lot of glue to make it work in a large organization, which is why things like kiln exist. You may ...


6

Very good, especially given perforce's competition (cvs, svn, etc) over most of its life, but no, not as good as Git. I can't speak to hg. While some of this is off-base (the p4 shelf is now an old feature, no, you can't make a dvcs behave just like a vcs, and it seems silly to knock p4 for xcode dropping support) the choice bits about p4 merging headaches ...


6

It's not terribly difficult to set up a pull request flow on a CVCS, it's just that no one does because they don't want to manage a gazillion personal branches on the server. Perforce is one of the rare CVCS vendors trying to address this by introducing features like streams and sandbox. There is one way DVCS distinguishes itself. It gives you more ...


5

In our line of work, it's sometimes difficult to see the human element. I believe DVCS has the potential to speed up a workflow, but a large number of developers are either unable or unwilling to learn it well enough to use it to its full potential. In my experience, around 1 in 10 developers already get it, another 2 in 10 would learn and use it to ...


5

The most important thing is to have a clear idea of what the standard workflow will be - how you will use branches and what gets pushed to the central repository. A DVCS can be used in many ways, from a centralized model with everyone working on a single branch to sharing changes between developers without having a central server at all. The command ...


5

People accidentally breaking other's builds or stepping on each others' toes while submitting code revisions This is an issue with organizational communication and programmer discipline. A DVCS is actually likely to make things worse in this situation, because individual programmers can keep working in their isolated repositories and not discover merge ...


4

I'm in the process of writing my own white paper about my experience with converting from SVN to Git as I've mentioned in the comments. Here's how I won over our IT guys. I don't have the exact numbers off hand, but the VM containing the SVN repo for our project was near 12-14gb of usage. When it came to an actual checkout, it was near 4.06gb coming down. ...


2

Yes. In day to day coding, there is not much of a difference time-wise whether you use one or other source control. As for the learning curve of a new methodology in a group: the larger the group the steeper the curve.


2

It depends on how you use Perforce. I seen the 'everyone has a branch' approach and 'everyone uses the same branch' approach. I worked as a Release Engineer in a company that used to former approach and never had any issues.


1

This really depends on your development processes, build process, release management, and branch management. You need to pick the best VCS to support these without worrying about if it's centralized or distributed. The VCS should support your processes and you should not have to mold your processes to the VCS (within reason).


1

One item I one consider is to look at 'same name, different functionality' issues. One of these that I've experienced with a git(dvcs)-svn(cvs) paradigm is that branching is different. In svn one tends to branch more, this workflow partly reflecting the fact that you can't "commit locally". When svn folks move to git, they need to learn what branches mean ...


Only top voted, non community-wiki answers of a minimum length are eligible