This project is read-only.

Change Source Control from Mercurial to TFS

Nov 7, 2011 at 9:26 PM

The DotSpatial team is considering changing the version control system from Mercurial to TFS (Team Foundation Server)

Reasons for this planned change are:

  1. We want the version control system to be easier to use for developers
  2. Some developers without Mercurial training were committing code that didn't build (missing files, incorrect references) and they were also committing extra heads (unnamed branches)
  3. Unlike Mercurial, the codeplex TFS can also be used with TortoiseSVN. Therefore, TortoiseSVN users will also be able to get DotSpatial code without learning a new system.

Please post any comments, concerns or objections here.

Nov 7, 2011 at 9:34 PM

Does this work only in Windows? It is at odds with getting DotSpatial to work in Linux and Mac. You have to think cross-platform. What's wrong with good old Subversion?

Nov 7, 2011 at 9:35 PM

I would be happier using a Subversion client as I am more familiar with it. I have not learned to use any of the differentiating features of Mercurial and as far as I know they have not been useful to this project.

Nov 7, 2011 at 10:00 PM

 You might simply need to enforce better practices, and manage the repository and builds. Might not be possible for a project the grows by accretion.

 

requirements:

  • committed code builds... moving does not solve this
    • Caused by inexperienced developers
    • or Caused by large scale changes to large project, everything is interdependent.
  • Desire to use SVN
    • TFS/SVN is a hack. Everyone either uses TFS, or they use the TFS/SVN.

 

Different question. Is this caused by one large repository? Smaller projects, linked together... (nuget).

In mercurial it's harder to manage a large project as a single projects. Smaller is better. Simply, think about splitting it into smaller libraries.  

Committed code. Use the automated build system to it's fullest. TeamCity includes the ability to do personal/pre-commit builds.

Use the capabilities: People doing large scale changes need to do it on a fork, ask for a code freeze, then merge. 

 

SVN :

  •  no intermediate commits. aka, no local change repository of you changes for when you are working
  • changes in one directory usually mean you don't have to pull changes

 

Mercurial :

  • you have to commit twice (or configure you client). 
  • you need to pull changes before committing, even if the changes are not in your area

 

Nov 7, 2011 at 10:17 PM

Version control systems come in two basic flavors: centralized repository and distributed repositories. There is nothing about this project that indicates the use of a distributed version control system like Mercurial. I vote for Subversion, since it is the best all-around centralized repository version control system.

This project has been Microsoft-only for a long time, but now that is no longer the case. Every single decision must take Linux, Mac and Mono into account. This means you cannot use a version control system that offers only Microsoft client interfaces. Again, Subversion fits the bill, while Team foundation Server does not.

Subversion integrates into Visual Studio and just about every other IDE under the sun. The only version control system that is more ubiquitous is CVS, but it has issues that Subversion was designed specifically to address.

Nov 7, 2011 at 11:28 PM
valentinedwv wrote:

Committed code. Use the automated build system to it's fullest. TeamCity includes the ability to do personal/pre-commit builds.


I tried using the Visual Studio addin for pre-commit builds and the server seemed to be too out-of-date at that time. I'll try this again.

Will we have access to this server past December? I've been working to get http://teamcity.codebetter.com up so we can use it after the new year.

 

I think this will help prevent bad check-ins regardless of source control system.

Nov 7, 2011 at 11:29 PM
ckonstanski wrote:

This project has been Microsoft-only for a long time, but now that is no longer the case. Every single decision must take Linux, Mac and Mono into account. This means you cannot use a version control system that offers only Microsoft client interfaces. Again, Subversion fits the bill, while Team foundation Server does not.

Why do you feel that TFS wouldn't work on Linux? See http://www.microsoft.com/download/en/details.aspx?id=4240

Nov 7, 2011 at 11:35 PM

In my experience (OpenNSPECT), the SVN system didn't exactly understand file renames made in TFS. Apparently DEslinger's workaround was to re-clone the repository at that point. I didn't ever look into this further.

 

At some point the team made the decision to switch from SVN to Mercurial, so I'd like to hear the reasoning made at that time. From my understanding SVN (or the SVNBridge) didn't even work for several situations.

Nov 8, 2011 at 7:19 AM

Even though I got downgraded :) I'd strongly urge you not to rely on TFS with SVNBridge.

TFS does not understand branches/tags created over SVNBridge as 'branch'/'tag', they are just new folders. That can lead to lots of frustration when you try to merge things to/from the created branch.

As someone said above: TFS/SVNBridge is a hack.

Cheers FObermaier

 

Nov 8, 2011 at 2:03 PM

Only source control system I am familiar with is Visual SourceSafe.  I had to spend a week learning enough Mercurial to not be dangerous and I am now semi-comfortable with it.  My small vote is to stick with Mercurial. 

Nov 8, 2011 at 5:07 PM

I personally think that Subversion (TortoiseSVN) is the easiest-to-use source control system, but Subversion is completely unreliable on codeplex.com because it uses SVN Bridge.

Main problems were the issues described by FObermaier: problems renaming files, deleting files, adding new folders. That was the main reason why Ted Dunsford (the chief DotSpatial developer 1 year ago) switched the system from Subversion to Mercurial and forced all DotSpatial developers to learn Mercurial

From reading the contributions here:

1. It is important that the version control system works reliably both on Windows and on Linux.

2. Proper training of developers how to use the version control system is necessary - including good tutorials and enforcing best practices

3. It is recommended to break up DotSpatial into several separate Codeplex projects. For example, all extensions (plugins) could be a separate codeplex project and GDAL data extension could also be a separate project.

4. Changing the version control system always adds extra time for developers who are not familiar with the new system and it may deter some potential open source developers from contributing code.

Any thoughts?

Nov 8, 2011 at 6:26 PM

Jiri,

That is a good summary of the issues, I think.  Should we consider hosting DotSpatial on something other than codeplex to allow a reliable switch to SVN?  Also, breaking it up into several projects is a good suggestion.  I never have liked how we had GDAL DLLs included in the one big source tree, because that initial clone would timeout.  I know you and I and others wasted a lot of time trying to get past that problem.

To make my Mercurial life easier, I usually try to get completely up-to-date before I commit a changeset to my local repo, then immediately turn around and post it to codeplex.  That keeps me from having to merge heads into targets and getting all confused.

Kyle