Rev 2267: Empty BRANCH.TODO; things to do in the future are moved into launchpad bugs in file:///home/mbp/bzr/Work/tags/

Martin Pool mbp at sourcefrog.net
Thu Mar 1 04:37:12 GMT 2007


------------------------------------------------------------
revno: 2267
revision-id: mbp at sourcefrog.net-20070301043643-ho3snagjdl64a96g
parent: mbp at sourcefrog.net-20070301042655-ib2mllvaozai23c6
committer: Martin Pool <mbp at sourcefrog.net>
branch nick: tags
timestamp: Thu 2007-03-01 15:36:43 +1100
message:
  Empty BRANCH.TODO; things to do in the future are moved into launchpad bugs
modified:
  BRANCH.TODO                    BRANCH.TODO-20060103052123-79ac4969351c03a9
=== modified file 'BRANCH.TODO'
--- a/BRANCH.TODO	2007-02-22 05:49:03 +0000
+++ b/BRANCH.TODO	2007-03-01 04:36:43 +0000
@@ -2,104 +2,3 @@
 # It should ALWAYS be empty in the mainline or in integration branches.
 # 
 
-Short-and-sweet implementation of tags for bzr
-
-Key features:
-
-Tags are stored in a repository.  Tags are pointers from names to revision
-ids.  Normally there should be a single universal definition for any tag
-name, though reality diverges from this in several important cases,
-including:
-
- * A new tag has been added in a repository, but not yet propagated to its 
-   mirrors.
-
-There is a single set of tag definitions visible by all operations within
-that repository.  The history of tags is not recorded (though we could
-perhaps record who made the tags and when, just for human reference).
-
-This patch modifies RepositoryFormatKnit2 to add tag support.  This 
-should be ok as this format is marked as experimental, though it has 
-shipped in previous releases.  If people are using it, and use an old 
-client to copy a repository it may lose the tag information.
-
-
-Done
-----
-
- - method to get tags from a repository - there are none at present
- - this should return nothing (or None) on old formats, or say that
-   it's not supported
- - add a new repository format which does have tags 
- - get a single tag, or complain if it's not defined
- - add a tag command which tags a revision, by adding an entry into the 
-   repository's tag dictionary
- - add tag:foo revision spec, and make sure it can be used 
- - separate tag storage into a strategy object?
- - raise TagsNotSupported on repositories that don't
- - make tag on arbitrary revisions
- - copy tags when cloning the repository
- - copy tags on push and pull
- - move tag operations onto branch
- - store tags in bencode format - or nul-delimited
- - test use of unicode tags
- - rename TagStore and change to branch.tags
- - delete tags, and mark as deleted
- - command to show all tags
- - make the experimental branch format available through a bzrdir format
- - if tag already exists, don't overwrite it
-
-Plan
-----
-
- - move merge-tags stuff into pull, push, merge, etc - not in command routines
- - raise an exception if the tag name is unreasonable
-   - see what happens if non-ascii byte string is given
- - if tags conflict when copying
-   - return them and give a warning
-   - option to override this and copy anyhow
- - refuse to add tags if the tag is already present, but allow it to 
-   be forced
- - maybe rename merge_to to merge_from (and invert the code)?
-
-
-Later
------
- - copy only selected tags
- - record who set tags, when, why
- - show tags in log
- - test copying tags between different branch formats?  a 
-   bit hard as there's only one at the moment...
-   - possibly better based on an InterBranch object
-   - could test between hpss and local branches
- - include tags in bundles?
-   (probably no point as not versioned)
-
-
-Also to do
-----------
-
-Are LockableFiles still really useful, rather than just?  Being lockable is
-perhaps not the point - rather that they have common conventions for how we
-treat our control files...
-
-Split repository.py into separate files for different formats?
-
-Have a single 'Experimental' format containing all work that's not yet
-released?
-
-A single method to get the contents of a (small) file as bytes of utf8 -- on
-Transport, I think, since many Transports can do that more efficiently than
-returning a file-like object.
-
-Keep the lock while constructing the Repository, so that we can call
-things that expect the lock to be held, and avoid taking or releasing it,
-or someone else seeing the half-constructed Repository.
-
-put_bytes_nonatomic may fairly often have the case of writing no content
-(and only creating the file) - we could test for and avoid one roundtrip.
-
-Split builtin commands into separate files, lazily loaded. 
-
- - Change commands to use a standard Registry.
- - Register commands lazily.




More information about the bazaar-commits mailing list