/stdhome

To get this branch, use:
bzr branch http://bzr.ed.am/stdhome

« back to all changes in this revision

Viewing changes to dev/todo.org

  • Committer: Tim Marston
  • Date: 2016-05-22 16:45:54 UTC
  • Revision ID: tim@ed.am-20160522164554-n5qhuibvnv0z4tk1
added general reporting to CopyBase and configured it via copy-in and copy-out
walkers (it is required in copy in, during add command); added -R (recursive)
flass to add command; allow vcs backends to augment statically ignored files
list; added detection of out of date working copy to bzr backend;
generate_walk_list() now takes a mandatory directory as the first argument;
don't copy entire subtree during copy of missing directory (as this makes
assumptions about what's in the walk-list)

Show diffs side-by-side

added added

removed removed

1
 
* perform update with conflict
2
 
 
3
 
* performing an "add", when the repo is not up-to-date (i.e., there are updates
4
 
   pending) just prints "stdhome add: bzr commit", with no other explaination as
5
 
   to what's going on
6
 
 
 
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
7
4
* add --all-files to `stdhome st` to show status of all files in repo?  or
8
 
   should we add `stdhome ls`?
9
 
 
 
5
   should we add `stdhome ls`? I'm favouring ls right now...
10
6
* symlink substitutes don't acept a symlink in the repo and a directory on the
11
 
   FS (as well as the other way around).  Should they?  It means ~/src (which is
12
 
   a symlink in my home repo) shows as modified when compared to the symlink of
13
 
   the same name on oak.
14
 
 
15
 
* skip unchanged directories
16
 
   now that update, revert, resolve and init report on home dir changes, resolve
17
 
   and revert show all directories as being modified (because we always copy
18
 
   them out without checking for changes)
19
 
 
 
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)
20
10
* add ~/bin/rebuild-tags!
21
 
 
22
 
* look at what need to be done before v0.1
23
 
 
24
11
* make the copy walker accept symlinks in place of files (as well as
25
12
   directories) if they are on the symlink accept list
26
 
 
27
 
* check that bin/quicktile.py on tims-laptop is an acceptable symlink
28
 
 
 
13
* look at what need to be done before v0.1
29
14
* !!! TAG 0.1 !!!
30
 
 
31
15
* check directory permissions before updating them
32
 
 
33
16
* during copy-out (not copy-in), show what is being changed with lines like
34
17
   "<SP><SP><OP><SP><FILE>" where OP is A (add), D (delete), M (modified) and K
35
18
   (kind change)
36
 
 
37
19
* currently, verbose print lines for bzr stuff are in the commands -- should
38
20
   they be in the bzr module?
39
 
 
40
21
* make the copy walker accept symlinks that differ if they are on the symlink
41
22
   accept list (so that symlinks can be pointed elsewhere in ~/)
42
 
 
43
23
* add code that can determine a relative file from a full file and a basepoint
44
 
 
45
24
* when ignoring files in the walker, populate the list of file more
46
25
   inteligently.  ".bzr" (and ".bzrignore") need to come from the VCS backend.
47
26
   ".stdhome", ".stdhomerc" and/or ".stdhomeignore" need to be converted to full
48
27
   filenames and then their relative file names derived from the configured home
49
28
   directory
50
 
 
51
29
* KNOWN ISSUE: handle renames as renames (rather than delete + add) because a
52
30
   directory renamed in the repo could contain other stuff that isn't versioned
53
31
   in ~/ which is lost, at the moment
54
 
 
55
32
* KNOWN ISSUE: decide on whether to implement remote --keep flag (see plan:483);
56
33
   currently, on the remote end, stuff deleted in repo during an update deletes
57
34
   files in ~/