~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to BRANCH.TODO

  • Committer: Martin Pool
  • Date: 2007-02-20 05:41:12 UTC
  • mfrom: (2220.3.2 tags)
  • mto: This revision was merged to the branch mainline in revision 2309.
  • Revision ID: mbp@sourcefrog.net-20070220054112-5ch1jqmy9m5zbk72
merge bencode licence, branch todo

Show diffs side-by-side

added added

removed removed

Lines of Context:
2
2
# It should ALWAYS be empty in the mainline or in integration branches.
3
3
4
4
 
5
 
Security: it should be impossible, by default, to access files above the base of
6
 
the backing transport of the SmartServerRequestHandler.  Currently '..' and the
7
 
like are not vetted, however.
8
 
 
9
 
Similarly, the SmartWSGIApp should also be careful to disallow '..' and the
10
 
like.
 
5
Short-and-sweet implementation of tags for bzr
 
6
 
 
7
Key features:
 
8
 
 
9
Tags are stored in a repository.  Tags are pointers from names to revision
 
10
ids.  Normally there should be a single universal definition for any tag
 
11
name, though reality diverges from this in several important cases,
 
12
including:
 
13
 
 
14
 * A new tag has been added in a repository, but not yet propagated to its 
 
15
   mirrors.
 
16
 
 
17
There is a single set of tag definitions visible by all operations within
 
18
that repository.  The history of tags is not recorded (though we could
 
19
perhaps record who made the tags and when, just for human reference).
 
20
 
 
21
This patch modifies RepositoryFormatKnit2 to add tag support.  This 
 
22
should be ok as this format is marked as experimental, though it has 
 
23
shipped in previous releases.  If people are using it, and use an old 
 
24
client to copy a repository it may lose the tag information.
 
25
 
 
26
 
 
27
Done
 
28
----
 
29
 
 
30
 - method to get tags from a repository - there are none at present
 
31
 - this should return nothing (or None) on old formats, or say that
 
32
   it's not supported
 
33
 - add a new repository format which does have tags 
 
34
 - get a single tag, or complain if it's not defined
 
35
 - add a tag command which tags a revision, by adding an entry into the 
 
36
   repository's tag dictionary
 
37
 - add tag:foo revision spec, and make sure it can be used 
 
38
 - separate tag storage into a strategy object?
 
39
 - raise TagsNotSupported on repositories that don't
 
40
 - make tag on arbitrary revisions
 
41
 - copy tags when cloning the repository
 
42
 - copy tags on push and pull
 
43
 
 
44
Plan
 
45
----
 
46
 
 
47
 - move tag operations onto branch
 
48
 - store tags in bencode format - or nul-delimited
 
49
 - test use of unicode tags
 
50
 - delete tags, and mark as deleted
 
51
 - record who set tags, when, why
 
52
 - tests that -d accepts urls, etc
 
53
 - copy only selected tags
 
54
 - if tags conflict when copying
 
55
   - return them and give a warning
 
56
   - option to override this and copy anyhow
 
57
 - give a nice message when trying to copy tags if it can't be done
 
58
 - when fetching revisions, also copy tags
 
59
   - give a warning if the tags differ, and don't override them
 
60
   - allow this to be forced
 
61
 - raise an exception if the tag name is unreasonable
 
62
 - refuse to add tags if the tag is already present, but allow it to 
 
63
   be forced
 
64
 - command to show all tags
 
65
 - command to remove a tag
 
66
 - show tags in log
 
67
 - test copying tags between different repository formats?  a 
 
68
   bit hard as there's only one at the moment...
 
69
 - include tags in bundles?
 
70
 
 
71
 
 
72
Also to do
 
73
----------
 
74
 
 
75
Are LockableFiles still really useful, rather than just?  Being lockable is
 
76
perhaps not the point - rather that they have common conventions for how we
 
77
treat our control files...
 
78
 
 
79
Split repository.py into separate files for different formats?
 
80
 
 
81
Have a single 'Experimental' format containing all work that's not yet
 
82
released?
 
83
 
 
84
A single method to get the contents of a (small) file as bytes of utf8 -- on
 
85
Transport, I think, since many Transports can do that more efficiently than
 
86
returning a file-like object.
 
87
 
 
88
Keep the lock while constructing the Repository, so that we can call
 
89
things that expect the lock to be held, and avoid taking or releasing it,
 
90
or someone else seeing the half-constructed Repository.
 
91
 
 
92
put_bytes_nonatomic may fairly often have the case of writing no content
 
93
(and only creating the file) - we could test for and avoid one roundtrip.
 
94
 
 
95
Split builtin commands into separate files, lazily loaded. 
 
96
 
 
97
 - Change commands to use a standard Registry.
 
98
 - Register commands lazily.