monotone-devel
[Top][All Lists]
Advanced

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

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


From: Richard Levitte - VMS Whacker
Subject: Re: [Monotone-devel] restrictions and SVN type branches/tags?
Date: Tue, 03 Aug 2004 08:14:56 +0200 (CEST)

In message <address@hidden> on Mon, 02 Aug 2004 21:35:38 -0600, Derek Scherger 
<address@hidden> said:

derek> Richard Levitte - VMS Whacker wrote:
derek> > But this builds on subversion's implementation of branches and tags as
derek> > new directories.  In monotone, branches and tags are special
derek> > certificates connected to each version of a file, and has no
derek> > association with directories at all, so basically, the above would be
derek> > utterly meaningless.
derek> 
derek> As I understand it tags (and most, if not all other certs) are
derek> associated with manifests, not files

Of course.  Darnit, I'm not off CVS thinking yet, it seems :-).

The same goes for subversion, BTW, it applies revision numbers to
whole changesets, not individual files.

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

I'm not sure I followed.  Does that mean that you can select what
particular files should be part of the change you're about to commit?
I would actually enjoy such a possibility, as the way I hack around
sometimes includes changes that really do not belong in the database.

derek> Creating a branch is really nothing more than just putting a
derek> new branch cert on some manifest.

Hmm, isn't that a bit simplistic?  I'm not entirely sure how branching
is supposed to work, but doesn't what you say mean that a specific
manifest is changed to belong to the new branch, thus affecting
everyone who happens to update from the same head as you do?  If that
is so, I will probably see that as a bug.

In my experiments, I've created branches by setting a different one
with --branch at the first commit to the new branch.

derek> Interestingly, one of the changes that graydon has made
derek> recently (and I think is in 0.14) is to prevent a commit when
derek> no changes have been made in the working copy. Previously this
derek> might have been the way to create a new branch before any
derek> changes have been made.

Ah, yes, I tried that, and was a bit surprised when another working
directory suddenly was in the new branch.  I can't say for sure if
that really was the effect of creating a branch that way, or if I made
some other mistake.  I'm still quite new to monotone, and
experimenting a lot...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/




reply via email to

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