monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Re: deleting branches, keys, etc.


From: Georg-W. Koltermann
Subject: Re: [Monotone-devel] Re: deleting branches, keys, etc.
Date: Mon, 04 Oct 2004 11:28:32 +0200

Hi,

this seems to get into brainstorm and discussion mode, so maybe I should
add my opinion in here even if I only understand matters from the user
perspective.

1st point: 

CVS pragmatically avoids any kind of "undo".  You can modify but not
delete.  If you did the wrong thing (tm), you undo by applying the
change backwards.

I would think that's a virtue.  KISS.  Maybe it makes sense to add such
features at version 7.15, but at pre-1.0 I think we can live without it.

If you anticipate problems, you can always copy your monotone.db for
safe keeping before you make large scale changes.  Then you can always
go back to a sane state.

2nd point: 

Naming is a problem in distributed systems.  What is a good name at one
end of the world may be a bad name at the other.  You may be forced to
change names because of copyrights, changes of ownership, project
rebranding, whatever.  So yes, I see a valid case for renaming branches.

What about adding a level of indirection to branch names?  A branch
might have a unique, frozen name internally, and each monotone instance
(i.e. local database) could register a human-friendly alias.  OpenCM
does it that way, on a per-user level.  They use random numbers for the
internal frozen name of branches, which we might do as well.

Then when you rename a branch, you only change your local alias to it.

I realize that having local aliases which might be different at each
instance also bears the danger of confusion.  So as a variation of this
theme, maybe we could transmit the branch name mapping when we
replicate.  Think of the mapping table as a special file like a manifest
which can get updated, appended, forked and merged again.

Just my $0.015, of course.  Press "D" if you don't like.

--
Regards,
Georg.






reply via email to

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