Re: [Monotone-devel] restrictions and SVN type branches/tags?

[Derek Scherger]

Richard Levitte - VMS Whacker wrote:
> In message <address@hidden> on Mon, 2 Aug 2004 16:56:27 +0200, Tobias Hunger 
> <address@hidden> said:
>
> tobias> Having said that, I was wondering whether subversion-style
> tobias> branching/tagging would be an option with that code.
> tobias> Subversion has no special support for those operations but
> tobias> recommends a tree structure like this:
> tobias> /
> tobias> +- trunk
> tobias> +- branches
> tobias> +- tags
> tobias> 
> tobias> The trunk directory holds the head version (in monotone's case
> tobias> the heads) of the sources. To tag a version you just copy the
> tobias> head over into the tag directory. Branching is a similar copy
> tobias> operation. Copy of course does not duplicate the data but sets
> tobias> up the database "symlinking" to the file/version.
>
> But this builds on subversion's implementation of branches and tags as
> new directories.  In monotone, branches and tags are special
> certificates connected to each version of a file, and has no
> association with directories at all, so basically, the above would be
> utterly meaningless.

As I understand it tags (and most, if not all other certs) are associated with manifests, 
not files, and it seems that a tag is really not much more than a symbolic name for some 
manifest version. Tagging a version is not much different than saying symbolic version 
"monotone release 0.14" is manifest a4a197a9ad2f14ee2e4aee4ba8e5bf7f483f731c. Nothing is 
getting copied.

The restriction code that I've done so far simply restricts the set of changes between two 
manifests (M1 and M2) to some smaller subset of changes and creates a third manifest 
(M1.5) by applying this subset of changes to the first manifest (M1). This is almost 
exactly what you might get by doing a monotone diff and then removing some changes from 
the diff output before applying it as patch to a clean copy of the checked out version the 
diff was made against. The only difference is that you might manually remove only some 
changes for a particular file, while the current restriction code will either include 
everything for some file or remove all of it since it is restricting on the level of files.

Branches are just another cert that are also associated with manifests and these certs are 
used when determining which manifests are candidates for merges, heads, etc. (I'm probably 
gorssly over simplifying things here). Creating a branch is really nothing more than just 
putting a new branch cert on some manifest.

Interestingly, one of the changes that graydon has made recently (and I think is in 0.14) 
is to prevent a commit when no changes have been made in the working copy. Previously this 
might have been the way to create a new branch before any changes have been made. This no 
longer works, and what I did today to create a new branch for something was to say 
monotone cert <id> branch new.branch.name. This left manifest <id> with two different 
branch certs, so that it essentially exists in two separate branches. I don't think 
there's any problem with this but I'm not certain.

Graydon, or anyone else in the know, does this sound ok? Are there any negative 
implications to having two (or more) different branch certs on a manifest? Is monotone 
cert <id> branch some.branch.name now the way to create a new branch before any changes 
have been made?
--
Cheers,
Derek