To do list¶
The following is the current known “to do” list. This is above and beyond any list of issues on the google code site.
Branch, tag, commit support for seams¶
Priority: high
The weld XML file allows specifying a branch, tag or revision (commit id?) for a seam.
- It is not defined what happens if you specify more than one. Ideally this would not be allowed, and the user would be told so.
- I’m not sure what, if any, of the code takes notice of these.
push
certainly doesn’t. This needs fixing.
This is the most important thing to fix, and must be thoroughly tested.
XML file format¶
Priority: medium
The current XML file is laid out as:
<base name=A ... />
<seam base=A ... />
and so on, where the seams for a base must occur after the base entity.
Would we be better with a “more traditional” layout like:
<base name=A ... >
<seam ... />
</base>
which removes the need for the implicit ordering.
If we go for this change, we should add a “version” attribute to the <weld>
entity, and make this <weld name=XXX version=2>
so that we can continue
to support old format files.
(We could actually detect both styles of file by inspection, and support them that way, even allowing mixed format (!) files, but using a version number feels cleaner.)
Base and seam commands¶
Priority: medium
Adding, deleting and renaming seams (and bases) is fiddly. We should probably provide some commands to bundle up all the actions necessary. For instance:
weld add base <base_name> <uri>
- adds the base to the XML file, clones it into the “bases” directory (so the user can inspect it to figure out seam names).weld delete base <base_name>
- removes the base and all its seams from the XML file, deletes its clone from the “bases” directory if it is there, deletess all the seams from the weld.weld add seam <base_name> <seam_name> <from-dir> <to-dir>
- add the seam to the XML file (the base must already exist), and set up the seam. Doesn’t do agit commit
- that’s up to the user.weld delete seam <base_name> <seam_name>
- removes the seam from the XML file, and removes its directory from the weld. Again, doesn’t do agit commit
.weld rename seam <base_name> <old_seam_name> <new_seam_name>
Since creating the initial weld means writing an XML file, maybe we should
also provide weld init --empty <weld-name> <uri>
to create a weld with a
minimal XML file - the above weld add
commands can then be used to
populate it with something more interesting.
Technically, we can manage with just those, but it’s probably also friendly to provide:
weld move seam <base_name> <seam_name> <old_to_dir> <new_to_dir>
weld rename seam <base_name> <old_seam_name> <new_seam_name>
and maybe some others as becomes evident with time.
Weld origin URI¶
Priority: medium
Should we be checking this against the actual origin that we are using for the weld (i.e., check the origin URI declared in the XML file against the origin that git is using)?
What commands should check it, and what should they do if the values disagree?
Weld pull and push common code¶
Priority: medium
There is some common code between weld push and weld pull (pylint notices a small amount of it).
Moreover, it is possible that the “use git ls-files to find files and then
copy them
approach used by weld push might be applicable in weld pull as
well.
Furthermore, weld push uses a pushing/
directory to keep its temporary
files local - again, weld pull could do the same with a pulling/
directory. This has the advantage that a partially completed push or pull is
resumable over a system reboot (when the /tmp
files would be deleted).
Command line¶
Priority: low
weld -h
could be more informativeweld help
should be paged (as with muddle and git), and the formatting could be better.weld help <command>
should be implemented- Command line switches that only apply to one or two commands should not be
general (I’m thinking of
-tuple
and-edit
particularly)
Weld push commit message content¶
Priority: low
The commit message (in the base) from weld push
takes the form:
X-Weld-State: Pushed igniting_duck from weld frank
Changes were (in summary, topmost was applied last)
f0e6ceb Remove the earlier trailing comment
f00c9fc Add more trailing comments across the bases and to the weld
335718e One-duck: Also build one-duck, same as one
a75b292 One-duck: Add a comment to the end of the Makefile
- The header line is an
X-Weld-State: Pushed
line, in a different format from that used in the weld. It could be argued that it should- not be an
X-Weld-State
line (although I don’t think it can ever “escape” back into the weld and cause confusion) - use a different term than
Pushed
(just in case it did “escape”)
- not be an
- This is the only place that the weld name (as taken from the XML file) is
used (here it is
frank
) - is it actually useful, or should we be using something else? - I quite like having the short-form SHA1 commit ids in there, since they do relate back to the weld repository, but it could be argued that they are not of use.
Do remember that it is always possible to do weld push --edit
and edit
this text before it is committed.
- Should we make
--edit
the default, and provide a--no-edit
switch as well?
Output levels¶
Priority: low
We are probably still outputting too much text when --verbose
is not
specified.
We may be outputting too much or the wrong text when --verbose
is
specified.
I suspect we are not always outputting appropriate text (in order to be useful) when something goes wrong.
All of these need consideration.
(Over) use of git porcelain¶
Ideally we would use the git plumbing more, and git porcelain less, since the output of git porcelain is (in general) allowed to be a moving target.