VersionControlProblems » History » Version 7

Chris Cannam, 2010-11-07 10:20 AM

1 1 Chris Cannam
h1. Version Control Problems
2 1 Chris Cannam
3 1 Chris Cannam
Some problems that complete beginners face when trying to create and work with repositories using current version control systems.
4 1 Chris Cannam
5 1 Chris Cannam
h2. Subversion
6 1 Chris Cannam
7 1 Chris Cannam
 * Puzzlement over "recommended" trunk/branches/tags structure
8 1 Chris Cannam
9 1 Chris Cannam
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.
10 2 Chris Cannam
11 3 Chris Cannam
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.
12 3 Chris Cannam
13 2 Chris Cannam
 * Difference between repository and working copy
14 2 Chris Cannam
15 2 Chris Cannam
Not a problem for many people, but some seem to find the terminology confusing
16 2 Chris Cannam
17 2 Chris Cannam
 * Requirement to update/merge/resolve before commit if someone else has modified the repository
18 2 Chris Cannam
19 2 Chris Cannam
A good user interface can make this workflow clearer
20 2 Chris Cannam
21 2 Chris Cannam
 * Forgetting to "svn add" new files
22 2 Chris Cannam
23 2 Chris Cannam
User interface should make a prominent note of files that have been created since the last commit
24 2 Chris Cannam
25 2 Chris Cannam
 * Forgetting to use svn when renaming or removing files
26 2 Chris Cannam
27 2 Chris Cannam
 * Admin help required for corrupted working copy because of sensitivity to changes in .svn directories (reported)
28 3 Chris Cannam
29 3 Chris Cannam
h2. Mercurial
30 3 Chris Cannam
31 3 Chris Cannam
 * Requirement to pull/update/merge/resolve/commit before pushing if someone else has modified the repository
32 3 Chris Cannam
33 3 Chris Cannam
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:
34 3 Chris Cannam
35 3 Chris Cannam
 * Mystification over branches, particularly anonymous branch created when you pull before a merge
36 3 Chris Cannam
37 7 Chris Cannam
A good user interface can still help here by making the branch structure and origin of each change explicit -- many just pile up the change log in a single list.  Again, I'm generally not concerned with difficulties in deliberately using branches here as most people just won't, but with Hg unlike SVN you do need to be aware of branches because they happen whether you ask for them or not.  On the other hand, if the branch structure is made explicit, it arguably reflects better "what actually happened" than the linear change log (people really were working on the two different commits at the same time).
38 4 Chris Cannam
39 4 Chris Cannam
 * Forgetting to "hg add" new files
40 4 Chris Cannam
41 4 Chris Cannam
User interface should make a prominent note of files that have been created since the last commit
42 4 Chris Cannam
43 4 Chris Cannam
 * Forgetting to use hg when renaming or removing files
44 4 Chris Cannam
45 5 Chris Cannam
h2. Git
46 4 Chris Cannam
47 4 Chris Cannam
 * Forgetting to "git add" new files
48 4 Chris Cannam
49 4 Chris Cannam
User interface should make a prominent note of files that have been created since the last commit.  Note that git is friendlier than the others in how it deals with removing and renaming files.
50 4 Chris Cannam
51 4 Chris Cannam
What else?  I haven't really had any experience trying to explain Git to people.
52 4 Chris Cannam
53 4 Chris Cannam
The specific thing that bit _me_ with Git was pushing to a non-bare repo (i.e. trying to treat clones of repos on different machines as peers and push changes around between them), which led to some work that had been pushed to a repo subsequently being overwritten with work done locally in that repo but not yet committed.  Pushing to a non-bare repo is apparently now prohibited by default, though the terminology and concepts involved are arguably still pretty confusing.  Of course this would only have been an issue for people "running" their own repos -- if you always sync to Github or similar it would never bite you.