VersionControlProblems » History » Version 4
Chris Cannam, 2010-11-07 10:16 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 | 4 | 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 |
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 | 4 | Chris Cannam | h3. 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. |