VersionControlProblems » History » Version 3
Version 2 (Chris Cannam, 2010-11-07 10:03 AM) → Version 3/12 (Chris Cannam, 2010-11-07 10:06 AM)
h1. Version Control Problems
Some problems that complete beginners face when trying to create and work with repositories using current version control systems.
h2. Subversion
* Puzzlement over "recommended" trunk/branches/tags structure
When instructing people how to create new projects, it's arguably simplest to ignore this and go for a structure that places them directly in the project directory. But that still results in confusion when checking out other people's projects that do have a difference between root URL and trunk URL.
Note, I'm not counting "difficulty in doing branch merges" etc as a problem for new users of Subversion -- most people will simply never use branches so it's not an issue.
* Difference between repository and working copy
Not a problem for many people, but some seem to find the terminology confusing
* Requirement to update/merge/resolve before commit if someone else has modified the repository
A good user interface can make this workflow clearer
* Forgetting to "svn add" new files
User interface should make a prominent note of files that have been created since the last commit
* Forgetting to use svn when renaming or removing files
* Admin help required for corrupted working copy because of sensitivity to changes in .svn directories (reported)
h2. Mercurial
* Requirement to pull/update/merge/resolve/commit before pushing if someone else has modified the repository
A good user interface can make this workflow clearer (a bad one can make it almost impossible), but it is generally more complex than SVN because of:
* Mystification over branches, particularly anonymous branch created when you pull before a merge
A good user interface can still help here by making the branch structure explicit -- many just pile up the change log in a single list
Some problems that complete beginners face when trying to create and work with repositories using current version control systems.
h2. Subversion
* Puzzlement over "recommended" trunk/branches/tags structure
When instructing people how to create new projects, it's arguably simplest to ignore this and go for a structure that places them directly in the project directory. But that still results in confusion when checking out other people's projects that do have a difference between root URL and trunk URL.
Note, I'm not counting "difficulty in doing branch merges" etc as a problem for new users of Subversion -- most people will simply never use branches so it's not an issue.
* Difference between repository and working copy
Not a problem for many people, but some seem to find the terminology confusing
* Requirement to update/merge/resolve before commit if someone else has modified the repository
A good user interface can make this workflow clearer
* Forgetting to "svn add" new files
User interface should make a prominent note of files that have been created since the last commit
* Forgetting to use svn when renaming or removing files
* Admin help required for corrupted working copy because of sensitivity to changes in .svn directories (reported)
h2. Mercurial
* Requirement to pull/update/merge/resolve/commit before pushing if someone else has modified the repository
A good user interface can make this workflow clearer (a bad one can make it almost impossible), but it is generally more complex than SVN because of:
* Mystification over branches, particularly anonymous branch created when you pull before a merge
A good user interface can still help here by making the branch structure explicit -- many just pile up the change log in a single list