ANN: inofficial open SmartEiffel 2.x repository

Am Mittwoch, den 25.05.2005, 16:49 +0200 schrieb Patrick Mauritz:
> I'll take a look at the next few passes of repository updates, then open it
> up for general consumption (if things work).
things seem to work, so here's the announcement ;-)

I've created a monotone repository that tracks the SE snapshots. it's
available for anonymous read access, and due to the distributed nature
of monotone allows you to make versioned changes to your local
repository copy.
As for "open"ness, I'll give write access to anyone who asks for
uploading changes, but of course abuse leads to rights taken away again.

In a nutshell, this repository allows you to more easily:
 * track SE snapshots in a checkout with local changes
 * branch from SE development and merge again, thus
   keeping patches up-to-date with less work
 * colaborate with others on a branch

two minor issues, which I don't intend to fix for now in the automatic
import are:
 1. it doesn't try to generate a meaningful commit message
 2. there's a commit every few hours because of two time stamps
    in the source tree


a quick tutorial for fetching the repository and basic use:

- get monotone (http://www.venge.net/monotone ,
  http://www.venge.net/monotone/INSTALL in case you 
  can't use the binaries or don't want to)

- monotone --db=se.db db init
  to create a database where you store all revisions in

- monotone --db=se.db genkey [email protected]
  creates a keypair used to sign your changes.

- monotone --db=se.db pull 195.227.14.230 fr.loria.smarteiffel
  this pulls all branches from the server whose names start with
  "fr.loria.smarteiffel"
  it shows a key's fingerprint, which should match
  0f012271f17b1ed775684051a632f32b12a27892

  currently the initial checkout is about 5mb and might take 
  a while (due to extensive integrity checking in monotone),
  later updates are usually much smaller (depends on the amount
  of changes in the mean time, of course).

- monotone --db=se.db --branch=fr.loria.smarteiffel.se co SmartEiffel
  creates a directory "SmartEiffel" containing the latest changes in
  that branch (.se is the one that tracks the snapshots)

there are two additional files, .mt-attrs which is monotone's way of
storing "executable" attributes (they're applied automatically to
checked out files) and the directory MT/, which contains management
data.

now you've got a checkout you can work in. you don't need to lock files
or something like that to edit them, and adding/deleting/moving files is
easy:

- monotone add filename
  monotone drop filename
  monotone rename from to

  add, drop (ignore files wrt revision control) and rename files.

if you want to commit, I ask you to change the branch you're working in,
so the tracking branch stays clean.

- monotone --branch=fr.loria.smarteiffel.mychange commit
  commits the changes to the given branch. you might want to add some
  nickname or initials to the "mychange" part to keep it reasonably
  unique, eg: fr.loria.smarteiffel.oxygene.solaris

  the branch name is recorded in the MT/ directory, so for future
  commits in that checkout you just have to do "monotone commit"

  monotone starts your standard editor for a log message, asks for
  the password you gave your key, then records the change in your
  database (se.db above). it's not uploaded yet, so you don't need
  write permission for that!

to send them to the server (given that you gave me your public key, more
to that later), "monotone push" (yes, that simple) in your working copy
does that.
to get updates that happened on the server in the mean time, use
"monotone pull" in your working copy (it stores the path to the database
in MT/, and the database stores default arguments for "pull")

to update your working copy with changes on the same branch (in your
database), do

 - monotone update

for updates across branch boundaries, do

 - monotone propagate sourcebranch targetbranch, eg.

   monotone propagate fr.loria.smarteiffel.se \
   fr.loria.smarteiffel.oxygene.solaris

it merges both branches and pushes the result directly into the
database, so you'll need to do "monotone update" afterwards.

in case of conflicts, it will try to start a merge tool (kdiff3, meld,
xxdiff, emacs, vim) to let you resolve the problems. for more
information about how to change behaviour in this case, read the
documentation.


some things about key management: it's easiest to reuse your keys
(instead of new generating keys for every database you bootstrap), so
once you generated a keypair, do

 - monotone pubkey [email protected] > monotonekey.pub
   monotone privkey [email protected] > monotonekey.priv

obviously, the privkey should be stored reasonably safe and never given
out - otherwise other people could make commits in your name, not good.

when you "db init" a new database, you can read in those files with

 - monotone --db=yourdb.db read < thefile

if you want write access to the repository, send me your pubkey, and
I'll add you.


I'm finished with my small tutorial, there's much more to monotone, but
that would make this tutorial way too complex. the website given above
has links to in-depth documentation (html and pdf) which I can only
recommend.


comments, questions, etc welcome,
patrick mauritz