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

[Rob Schoening]

Keep in mind that when people used to using other VCSs ask about tags or labels, they may not understand that what they're asking for is already provided by monotone by way of the SHA1 revision id, albeit not with friendly user-defined names.

 

A common use-case is for development to tag a build and communicate that tag to build/release management who then creates an official build.  But often that build will be broken or some developer will have forgotten to commit some critical code.  Some organizations prefer to either move or re-tag the release.

 

However, this "issue" could be solved with monotone fairly easily by simply communicating the revision id instead of a tag and having the official tag created after the build is known to be good?  Just a workflow change.

 

Even though it wouldn't really help the use-case just described, the bookmarks idea is still a good one.  Would it be possible to implement this by allowing tags (or branches, for that matter) to be killed in the local database through a friendly command if no sync has occurred? 

 

This would help with the problem--common in my case--of the user simply making a mistake...typo in the name, creating a tag with something erroneously uncommitted, etc.

 

 I imagine that this must have been discussed many times before...and probably shot down for good reason....

 

RS
 

On 11/3/06, Chad Walstrom <address@hidden> wrote:

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 */



_______________________________________________
Monotone-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monotone-devel