← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to BRANCH.TODO

  • Committer: Martin Pool
  • Date: 2007-03-01 04:36:43 UTC
  • mto: This revision was merged to the branch mainline in revision 2309.
  • Revision ID: mbp@sourcefrog.net-20070301043643-ho3snagjdl64a96g
Empty BRANCH.TODO; things to do in the future are moved into launchpad bugs

Show diffs side-by-side

added added

removed removed

Lines of Context:
BRANCH.TODO
2
2
# It should ALWAYS be empty in the mainline or in integration branches.
3
3
# 
4
4
 
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
 
 - move tag operations onto branch
44
 
 - store tags in bencode format - or nul-delimited
45
 
 - test use of unicode tags
46
 
 - rename TagStore and change to branch.tags
47
 
 - delete tags, and mark as deleted
48
 
 - command to show all tags
49
 
 - make the experimental branch format available through a bzrdir format
50
 
 - if tag already exists, don't overwrite it
51
 
 
52
 
Plan
53
 
----
54
 
 
55
 
 - move merge-tags stuff into pull, push, merge, etc - not in command routines
56
 
 - raise an exception if the tag name is unreasonable
57
 
   - see what happens if non-ascii byte string is given
58
 
 - if tags conflict when copying
59
 
   - return them and give a warning
60
 
   - option to override this and copy anyhow
61
 
 - refuse to add tags if the tag is already present, but allow it to 
62
 
   be forced
63
 
 - maybe rename merge_to to merge_from (and invert the code)?
64
 
 
65
 
 
66
 
Later
67
 
-----
68
 
 - copy only selected tags
69
 
 - record who set tags, when, why
70
 
 - show tags in log
71
 
 - test copying tags between different branch formats?  a 
72
 
   bit hard as there's only one at the moment...
73
 
   - possibly better based on an InterBranch object
74
 
   - could test between hpss and local branches
75
 
 - include tags in bundles?
76
 
   (probably no point as not versioned)
77
 
 
78
 
 
79
 
Also to do
80
 
----------
81
 
 
82
 
Are LockableFiles still really useful, rather than just?  Being lockable is
83
 
perhaps not the point - rather that they have common conventions for how we
84
 
treat our control files...
85
 
 
86
 
Split repository.py into separate files for different formats?
87
 
 
88
 
Have a single 'Experimental' format containing all work that's not yet
89
 
released?
90
 
 
91
 
A single method to get the contents of a (small) file as bytes of utf8 -- on
92
 
Transport, I think, since many Transports can do that more efficiently than
93
 
returning a file-like object.
94
 
 
95
 
Keep the lock while constructing the Repository, so that we can call
96
 
things that expect the lock to be held, and avoid taking or releasing it,
97
 
or someone else seeing the half-constructed Repository.
98
 
 
99
 
put_bytes_nonatomic may fairly often have the case of writing no content
100
 
(and only creating the file) - we could test for and avoid one roundtrip.
101
 
 
102
 
Split builtin commands into separate files, lazily loaded. 
103
 
 
104
 
 - Change commands to use a standard Registry.
105
 
 - Register commands lazily.