monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bookmarks (was Re: [Monotone-devel] Tagging a revision?)


From: Chad Walstrom
Subject: Bookmarks (was Re: [Monotone-devel] Tagging a revision?)
Date: Fri, 03 Nov 2006 11:48:02 -0600

Johan =?iso-8859-15?q?Bolmsj=F6?= <address@hidden>  wrote:
> Wouldn't it be possible to make the TAGS mergable in the future, or
> is this a bad idea?

I'm not sure it's really needed.  We have magic selectors that are
just as effective as tags, really.  The way people generally used tags
in CVS was to denote when a branch takes place, or what revision of
the software was released.  A few people used the floating capability
of tags as a special "HEAD" indicator, but not as a floating release
indicator.  I do recall using _LATEST as the latest release, but that
was largely unnecessary.  Version number comparison is generally
sufficient to find out what the latest release is.

I'm not sure what benefit we would gain for trying to merge tags.

> If you had a file internally for each TAG with the revisions on each
> line that it currently map to. Of course maybe there would be a
> problem with how TAGS got synced when you do a pull/sync.. But maybe
> that could be solved.

Interesting.  Mercurial does keep tags in a file, IIRC.  They also
support the concept of local tags.  I think "bookmark" might be more
appropriate for a concept of a mutable "tag".  Perhaps a simple file
(.mtn-bookmarks) containing a key-pair in basic-io with a bookmark
name and revision or magic selector.

You could distribute that around with the project source, just like
.mtn-ignore.  Local bookmarks could be kept in a ~/.monotone/bookmarks
file again formatted via basic-io to include BRANCH_PATTERN,
BOOKMARK_NAME, and SELECTOR_STRING.

Alternatively, if you can store bookmarks in a table in the monotone
database, you could have a boolean field indicating whether or not the
tag should be local or not.  That way, we don't have to worry about
parsing or maintaining file formats.  You would need a way to export
the local tags and import them into new databases, therefore a file
might be more mobile/flexible, and could apply to wildcard branch
patterns.

Anyway, back to work.
-- 
Chad Walstrom <address@hidden>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */





reply via email to

[Prev in Thread] Current Thread [Next in Thread]