monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] some propositions


From: Zbigniew Zagórski
Subject: [Monotone-devel] some propositions
Date: Sat, 05 Jun 2004 15:10:23 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040526 Debian/1.6-6

Hello.
Thanks for answers for my previous questions.

I'm using montone for a while, so i've got some questions/suggestions.

1. push/pull
These commands could use actual branch in starting executed from working
copy. So the "collection" argument would be optional when in working copy.

2. pull
I think it should be possible, to pull server's public key automagically
if it's unknown. Warning if it's done would be good. It would simplify
first pull to invoke just
  db init
  pull
without "getting" public key from somewhere.

3. serve
3.1
    Why serve can't just serve all collections in database or the only
    one if only one exists.
3.2
   If i start server, then it has locked its provate key .. ok , but
   it needs terminal to unlock this key , and it waits to first use of
   this key.
   Is there way to create unprotected private key ?
   OK. I just found, i should make LUA callback that reads password, but
   it would be more nice to create "unprotected" private key.

4.
   There was discussion about netsync and ssh and reading from stdin. It
   would be good to "push/pull" to databases without net, as in
   BitKeeper where repository location is kind of uniform resource
   locator:
        ssh://address@hidden:repo
        bk://host:port/repo
        generic_path_to_repo_in_filesystem:
        /home/projects/monotone
   and so on.
   In monotone my proposition is:
        host:port                            - it would be netsync
        netsync://host:port
        ssh://address@hidden:database_path           - like in scp
        /home/projects/monotone              - localal filesystem
        file://mydir/db/monotone.monodb      - local filesystem

If push/pull/sync would read such addresses and if netsync would read
from stdin then it would be easy (i don't know about key/cert issuses
with this) to migrate data in various ways.
Next, such uniform locator stored it MT/options with default branch
would provide default values for push/pull/sync parameters.

5. This very big proposition for very far furure.
Maybe each file change should be commented ? I worked a lot with
BitKepper which have comments on each file in manifest apart from
manifest comment, and i found it very useful.
In bigger project it's good to comment each file change and in
manifest/changeset put only summary.
Next problem, in current system it's impossible to track changes of one
file with comments. We can see diff for each file revision, but comment from
manifest.

6. It would be good to choose which files or actions in MT/work are to
be commited.

7. New commands
  monotone make-packet-patch first-ID last-ID

Should generate set of packets that contain all manifests from start-id to end-id and all file revisions contained in these. So that if i later
do
   monotone read < such_generated_packet_set

all changes from these manifests are in my database.
Well, am i undesrtand packet system correctly ?


I know that it's lot, and best would be if i choose some and try to
implement it, but currently i have no time/environment(note about amount of RAM needed to compile is absolutely true) for developing monotone and next i'd like to, and it's good to ask for opinion before doing something.

Thanks

::: zbigg ::::::::::::: Zbigniew Zagórski ::
:: zzbigg (at) o2 (dot) pl ::: GG:5280474 ::
:::: http://zbig.pentagon.eu.org/ ::::::::::


--
Zbigniew Zagórski ::::::::::::::::::::::::::
:: zzbigg (at) o2 (dot) pl ::: GG:5280474 ::
:::: axlhome.host.sk :::::::::::::::::::::::




reply via email to

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