Re: [Monotone-devel] Future of monotone

[Thomas Keller]

address@hidden schrieb:
> On Sun, Jan 27, 2008 at 02:41:37PM +0100, Thomas Keller wrote:
>
> > So where lacks monotone the most? 
>
> Here's my list:

I think it would be a good idea to check / prioritize the list here:

http://venge.net/mtn-wiki/MtnSummit/Ideas

And of course its always possible to add more (non-duplicate) items there.

>     - allow commit of sub-file patches

Yes, this seems useful. Want to lend a helping hand there? There was 
already some discussion recently about this topic. What implementation 
would you prefer?

>     - support of symlinks

Symlinks could be supported with hooks right now, but if you want to 
have this into mtn core we'd need somebody with experience on Win32 i.e. 
how symlinks could be handled there.

>     - policy branches

Hehe...

>     - clean up the UI
>         - smarter heuristics for identification of revisions, branches, etc.

So, smarter selectors? What do you think of here exactly? More 
tree-based selectors? F.e. I found the recent addition of p: quite 
useful. What are your use cases?

>         - selectors don't like branches with '/' in them

IIRC its possible to escape them with \, but if this does not work, this 
could probably be just a bug.

>         - rename 'up' to 'switch'

Before this is done we should fiddle with the possible semantics of 
switch and update before (there was a discussion about this a few months 
ago). Switch should actually be more aware of _MTN/options entries and 
update should then solely be used to update to the most recent head of 
whatever branch is mentioned in _MTN/options.

>         - have a command to create a new named branch

This is fairly easy to add, it can already be done with `mtn cert`.

>     - allow splitting a branch into multiple branches (the inverse of
>       merge_into_dir)

I think splitting is not the problem here, but more the possibility that 
these two "branches" should be mergable later on.

>     - allow replacing the root revision with another revision 

Whats the intention here?

>     - allow combination of a revision chain into a single revision (compress
>       the history graph)

This and the one before would completly break the history, thus all 
revisions would have to be recalculated starting from the "compacted" 
ones. A better approach would be:

$ mtn co -b some.branch
$ cd some.branch
$ rm -rf _MTN
$ mtn setup -b some.branch.new .

> You could always through speed in there...

Yeah, speed for log and initial pull.

Thomas.

--
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature