Skip to main content
Software Engineering

Return to Answer

Commonmark migration
Source Link
Community Bot
Community Bot
  • 1

I have no personal experience with DVCS, but from what I gather from the answers here and some linked documents, the most fundamental difference between DVCS and CVCS is the used working model

DVCS

###DVCS TheThe working model of DVCS is that you are doing isolated development. You are developing your new feature/bugfix in isolation from all other changes until the moment you decide to release it to the rest of the team. Until that time, you can do whatever check-ins you like, because nobody else is going to be bothered with it.

CVCS

###CVCS TheThe working model of CVCS (in particular Subversion) is that you are doing collaborative development. You are developing your new feature/bugfix in direct collaboration with all the other team members and all changes are immediately available to all.

Other differences

#Other differences# OtherOther differences between svn and git/hg, such as revisions vs changesets are incidental. It is very well possible to create a DVCS based on revisions (as Subversion has them) or a CVCS based on changesets (as Git/Mercurial have them).

I am not going to recommend any particular tool, because it mostly depends on the working model that you (and your team) are most comfortable with.
Personally, I have no problems with working with a CVCS.

  • I have no fear of checking in stuff, as I have no problems getting it into a incomplete, but compilable state.
  • When I experienced merge-hell, it was in situations where it would have occurred in both svn and git/hg. For example, V2 of some software was being maintained by a different team, using a different VCS, while we were developing V3. Occasionally, bugfixes would have to be imported from the V2 VCS to the V3 VCS, which basically meant doing a very large check-in on the V3 VCS (with all bugfixes in a single changeset). I know it was not ideal, but it was a management decision to use different VCS systems.

I have no personal experience with DVCS, but from what I gather from the answers here and some linked documents, the most fundamental difference between DVCS and CVCS is the used working model

###DVCS The working model of DVCS is that you are doing isolated development. You are developing your new feature/bugfix in isolation from all other changes until the moment you decide to release it to the rest of the team. Until that time, you can do whatever check-ins you like, because nobody else is going to be bothered with it.

###CVCS The working model of CVCS (in particular Subversion) is that you are doing collaborative development. You are developing your new feature/bugfix in direct collaboration with all the other team members and all changes are immediately available to all.

#Other differences# Other differences between svn and git/hg, such as revisions vs changesets are incidental. It is very well possible to create a DVCS based on revisions (as Subversion has them) or a CVCS based on changesets (as Git/Mercurial have them).

I am not going to recommend any particular tool, because it mostly depends on the working model that you (and your team) are most comfortable with.
Personally, I have no problems with working with a CVCS.

  • I have no fear of checking in stuff, as I have no problems getting it into a incomplete, but compilable state.
  • When I experienced merge-hell, it was in situations where it would have occurred in both svn and git/hg. For example, V2 of some software was being maintained by a different team, using a different VCS, while we were developing V3. Occasionally, bugfixes would have to be imported from the V2 VCS to the V3 VCS, which basically meant doing a very large check-in on the V3 VCS (with all bugfixes in a single changeset). I know it was not ideal, but it was a management decision to use different VCS systems.

I have no personal experience with DVCS, but from what I gather from the answers here and some linked documents, the most fundamental difference between DVCS and CVCS is the used working model

DVCS

The working model of DVCS is that you are doing isolated development. You are developing your new feature/bugfix in isolation from all other changes until the moment you decide to release it to the rest of the team. Until that time, you can do whatever check-ins you like, because nobody else is going to be bothered with it.

CVCS

The working model of CVCS (in particular Subversion) is that you are doing collaborative development. You are developing your new feature/bugfix in direct collaboration with all the other team members and all changes are immediately available to all.

Other differences

Other differences between svn and git/hg, such as revisions vs changesets are incidental. It is very well possible to create a DVCS based on revisions (as Subversion has them) or a CVCS based on changesets (as Git/Mercurial have them).

I am not going to recommend any particular tool, because it mostly depends on the working model that you (and your team) are most comfortable with.
Personally, I have no problems with working with a CVCS.

  • I have no fear of checking in stuff, as I have no problems getting it into a incomplete, but compilable state.
  • When I experienced merge-hell, it was in situations where it would have occurred in both svn and git/hg. For example, V2 of some software was being maintained by a different team, using a different VCS, while we were developing V3. Occasionally, bugfixes would have to be imported from the V2 VCS to the V3 VCS, which basically meant doing a very large check-in on the V3 VCS (with all bugfixes in a single changeset). I know it was not ideal, but it was a management decision to use different VCS systems.
Source Link
Bart van Ingen Schenau
Bart van Ingen Schenau
  • 76.7k
  • 20
  • 125
  • 189

I have no personal experience with DVCS, but from what I gather from the answers here and some linked documents, the most fundamental difference between DVCS and CVCS is the used working model

###DVCS The working model of DVCS is that you are doing isolated development. You are developing your new feature/bugfix in isolation from all other changes until the moment you decide to release it to the rest of the team. Until that time, you can do whatever check-ins you like, because nobody else is going to be bothered with it.

###CVCS The working model of CVCS (in particular Subversion) is that you are doing collaborative development. You are developing your new feature/bugfix in direct collaboration with all the other team members and all changes are immediately available to all.

#Other differences# Other differences between svn and git/hg, such as revisions vs changesets are incidental. It is very well possible to create a DVCS based on revisions (as Subversion has them) or a CVCS based on changesets (as Git/Mercurial have them).

I am not going to recommend any particular tool, because it mostly depends on the working model that you (and your team) are most comfortable with.
Personally, I have no problems with working with a CVCS.

  • I have no fear of checking in stuff, as I have no problems getting it into a incomplete, but compilable state.
  • When I experienced merge-hell, it was in situations where it would have occurred in both svn and git/hg. For example, V2 of some software was being maintained by a different team, using a different VCS, while we were developing V3. Occasionally, bugfixes would have to be imported from the V2 VCS to the V3 VCS, which basically meant doing a very large check-in on the V3 VCS (with all bugfixes in a single changeset). I know it was not ideal, but it was a management decision to use different VCS systems.