bzr branch
http://bzr.ed.am/stdhome
81
by Tim Marston
updated todo |
1 |
* fix add/ci command's recursion |
2 |
if i go: stdhome ci ~/somedir, will it add the whole damn dir, or just the dir |
|
3 |
itsself? recursion needs to be requested, i think, by the -R switch |
|
68
by Tim Marston
added tools |
4 |
* add --all-files to `stdhome st` to show status of all files in repo? or |
78
by Tim Marston
updated todo |
5 |
should we add `stdhome ls`? I'm favouring ls right now... |
68
by Tim Marston
added tools |
6 |
* symlink substitutes don't acept a symlink in the repo and a directory on the |
78
by Tim Marston
updated todo |
7 |
FS (as well as the other way around). Should they? I can't think of a use |
8 |
case for this... Note: if this is changed, also update the StatusWalker |
|
9 |
(used by status and diff commands) |
|
68
by Tim Marston
added tools |
10 |
* add ~/bin/rebuild-tags! |
11 |
* make the copy walker accept symlinks in place of files (as well as |
|
12 |
directories) if they are on the symlink accept list |
|
78
by Tim Marston
updated todo |
13 |
* look at what need to be done before v0.1 |
68
by Tim Marston
added tools |
14 |
* !!! TAG 0.1 !!! |
15 |
* check directory permissions before updating them |
|
16 |
* during copy-out (not copy-in), show what is being changed with lines like |
|
17 |
"<SP><SP><OP><SP><FILE>" where OP is A (add), D (delete), M (modified) and K |
|
18 |
(kind change) |
|
19 |
* currently, verbose print lines for bzr stuff are in the commands -- should |
|
20 |
they be in the bzr module? |
|
21 |
* make the copy walker accept symlinks that differ if they are on the symlink |
|
22 |
accept list (so that symlinks can be pointed elsewhere in ~/) |
|
23 |
* add code that can determine a relative file from a full file and a basepoint |
|
24 |
* when ignoring files in the walker, populate the list of file more |
|
25 |
inteligently. ".bzr" (and ".bzrignore") need to come from the VCS backend. |
|
26 |
".stdhome", ".stdhomerc" and/or ".stdhomeignore" need to be converted to full |
|
27 |
filenames and then their relative file names derived from the configured home |
|
28 |
directory |
|
29 |
* KNOWN ISSUE: handle renames as renames (rather than delete + add) because a |
|
30 |
directory renamed in the repo could contain other stuff that isn't versioned |
|
31 |
in ~/ which is lost, at the moment |
|
32 |
* KNOWN ISSUE: decide on whether to implement remote --keep flag (see plan:483); |
|
33 |
currently, on the remote end, stuff deleted in repo during an update deletes |
|
34 |
files in ~/ |