[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Future of monotone
From: |
Thomas Keller |
Subject: |
Re: [Monotone-devel] Future of monotone |
Date: |
Mon, 28 Jan 2008 00:34:06 +0100 |
User-agent: |
Thunderbird 2.0.0.9 (Macintosh/20071031) |
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
Re: [Monotone-devel] Future of monotone, Brian May, 2008/01/28
[Monotone-devel] Re: Future of monotone, Graydon Hoare, 2008/01/28