Rewrite/improve the VCS modules

[GoogleCodeExporter]

Muddle tries to provide common commands for handling repositories in 
subversion, bazaar and git (for some reason, we don't have code for 
mercurial yet).

Clearly there is some difficulty in doing this well, with the very 
different models that these systems provide. The current functionality 
doesn't particularly fit well with git, for instance, and probably has 
quite significant assumptions about how bzr will be used.

We need to do a review of what is possible and sensible in each system, 
and also how they are actually used, to figure out what muddle wants to do 
(for instance, should muddle even *try* to support automated pushing for 
git projects?).

Original issue reported on code.google.com by t...@tibsnjoan.co.uk on 10 Mar 2010 at 12:07

• Blocked on: #126

[GoogleCodeExporter]

Known issues include lack of proper support for branches (the solution for git 
is workable but not elegant), and the duplicated code for handling checkouts 
and "bare" directories.

(Changed name of issue to reflect my current thinking on the matter)

Original comment by t...@tibsnjoan.co.uk on 14 Oct 2010 at 8:33

• Changed title: Rewrite/improve the VCS modules

[GoogleCodeExporter]

See issue 126 for the branch support issue

Original comment by t...@tibsnjoan.co.uk on 14 Oct 2010 at 9:20

[GoogleCodeExporter]

Original comment by t...@tibsnjoan.co.uk on 14 Oct 2010 at 9:21

[GoogleCodeExporter]

After some discussion (mainly between Ross and myself), the plan seems to be:

1. Develop on a branch (of course)
2. Rewrite the underlying VCS code so that the vcs/<name>.py code provides 
functionality that works on a directory, and version_control.py handles the 
mapping of a checkout to its directory. This simplifies the code that needs to 
be written to support an individual VCS (and unsplits the current split in the 
VCS specific code).
3. Change the toplevel muddle commands (and their help) to be easier to 
understand.

The top level commands will be (something like):

* muddle checkout -- still called 'checkout' rather than (for instance) 
'clone', because it produces a new checkout directory.

* muddle commit -- much as before, commits changes (for git, this would be a 
'commit -a'). Does nothing if there is nothing to commit.

* muddle push -- the same as before. Pushes changes to the remote repository, 
as indicated by the build description. I would propose that this does NOT do a 
commit as part of its work - instead it should "grumble" (see below) about a 
checkout that has uncomitted data.

* muddle fetch -- this retrieves changes from the remote repository (as 
described by the build description), and applies them to the checkout (working 
set), but not if a merge would be required. If a merge would be needed, it will 
"grumble" (again, see below). Whether the local repository (for that checkout 
directory) will have been updated or not is VCS specific.

* muddle merge -- this retrieves changes from the remote repository (...), and 
applies them to the checkout (working set), doing any merge actions necessary. 
Merges are handled in a VCS specific manner. Doing 'muddle merge _all' may be 
unnecessarily exciting...

* muddle status -- I'm not 100% sure of the name for this one (perhaps 'muddle 
query status' would be better?), but it will report on any uncommitted or 
unadded files. The information reported will be VCS specific, but is basically 
stuff that might indicate that something needs committing. In fact, this may 
just be equivalent to the reporting that 'muddle stamp version' already does, 
but without generating the stamp file.

* 'muddle reparent' - this existed to correct situations where the data in the 
.<vcs> directory was not consistent with the remote repository indicated by the 
build description. As such, it should remain and continue to do the same thing, 
until we can prove it not needed (which may actually be possible with the new 
scheme of things - we shall see).

Note that, as before, changing the remote repository in the build description 
(that includes the "default" repository indicated by '.muddle/RootRepository') 
will change the remote repository used by the muddle commands.

"muddle pull" and "muddle update" will go away, because they are ambiguous - 
it's not even clear from the muddle help or docstrings what they are meant to 
do, and the varying VCSs use the terms in different manners.

The "dep-" and "pkg-" variants will also go away. Instead, if a 
checkout-oriented command is given arguments that start "package:", then it 
will determine the checkouts associated with that package, and add them to the 
set of checkouts to be processed by that command.

We said "grumble": As a principle, if multiple checkouts are being processed, 
and problems are reported for any of them, then a summary of the problems shall 
be presented at the end of the output. This means the user should not "lose" 
information far back in the output text.

The underlying VCS support will also provide limited support for "init"ing a 
directory and "add"ing some files to its VCS - this is for use in 'muddle 
bootstrap'.

Original comment by t...@tibsnjoan.co.uk on 21 Oct 2010 at 8:56

[GoogleCodeExporter]

The above envisaged development is now done, in muddle 2.2, r591. Branch 
support (as mentioned in issue 126) is still ongoing

Original comment by t...@tibsnjoan.co.uk on 16 Dec 2010 at 2:29

• Changed state: Fixed