Public SourceMage Discussion List

[Andrew <afrayedknot AT thefrayedknot.armory.com>]

Hi, thanks for bringing this up, Ive been trying to evaluate scms for
a while, and so I'll share my thoughts and views on what we want/need in
and scm.

> 
> 2.1 CVS
I basically agree with you on cvs, I think its old, and lacks a lot in the
way of branching/merging, features, history and all that stuff... I've
also had way too many screwed up repositories and stuff from using it
just as a single user between two machines, in other words, i dont trust
it with my data.

> 
> 2.2 Subversion (SVN)

I like subversion, its got most of what I want in it, and its got
a nice simple mechanisms to do branching and merging. The problem
is that it lacks history, and merging changing from seperate development
lines can be pretty ugly since you have to manually figur out what
changes to apply. Perforce does this for us which makes it very appealing.
Svn is essentially just a versioned file system, and we need a bit more
than that.

> 
> 
> 2.3 tla (GNU/Arch)

Arch, where do I start. If arch was easier to use and more intuitive,
I would be lobbying for it almost exclusively. Arch has a very good support
for branching and merging, and with a little bit of adjusting I could
probably adapt sorcery to fit into their model. Its also fully
decentralized which makes mirroring easy, and you can seemlessly move
changes between repositories, I think my favorite arch feature is
the autogenerated Changelogs. Right now with sorcery we get to merge
changelogs as we move code between devel/test/stable. Its quite
frustrating to get it all right.


The problem I had with arch is that all the commands they have are two
low level, I've heard this is a common complaint, for example theres a
make-branch command, but its 1) not documented on their tutorial and 2)
I cant get it to work without using some other undocumented low level
commands. The whole thing seems fairly un-intuitive, and despite the fact
that it can do a good job managing my source code, I dont want to have
to spend any more time than i have to trying to figure out how to
do something. I think that we can solve all those problems by making
all the common tasks into bash scripts, but then it becomes a quesiton
of whether or not we have the time, or energy to put there.

My conclusion after spending a week with it was that we should wait for
it to mature a bit, and its the most promising.


> 
> 2.4 others (Aegis, Monotone...)
I looked at monotone a little bit, but it seemed like cvs with a few
things improved in it, in other words there wasnt an obvious way to
make strict branches, the way Im used to.

Aegis looked pretty cool, its got a huge number of commands, but
also seems to have the features we're interested in. If I have time
I'll look into it as well, it may very well be our solution.

As far as what I think we need in an scm heres my rough list:
* merging must be able to automatically figure out what changes to merge,
  rather than making the user do it, more on this later.
* partial commits, perforce and svn do this, and its very convenient,
  tla can sort of do this, but its more of a hassle, often times you
  have to do a tla undo/redo to get it right. Otoh with tla its fairly
  easy to duplicate the project you're working on since its completely
  decentralized. I actually have a couple sorcery trees i work on
* change emails, perforce has this built in, and i think we can build
  it on of any other scm, just by having a daemon on the main repository
  machine looking for changes out of band and sending out emails.
* history, its nice to be able to follow history backwards and see where
  changes came from, or if you merge files, the scm should know that you
  merged them. svn doesnt do this at all, a merge looks just like an edit
  to svn so you have to manually record it in the changelog, this should
  be done automatically.
* auto changelog generation, this isnt strictly necesary but I think it would
  make all of our lives easier. Spell HISTORY files could just be
  generated from the checkin messages, as well as the sorcery changelog.
* permission control, perforce does this all for us and its really
  nice, other scms tend to use webdav as their permission control enabled
  protocol, so everyone gets to access the repository through it. This isnt
  such a big deal for us because then the main repository doesnt need user
  accounts for every developer.

We have two fairly different arms to sourcemage, the grimoire and sorcery
(im not ignoring the iso, but theres not nearly as much branching and
merging in that end of things).  The grimoire model has devel test
and stable, and changes get pulled from devel on a per spell basis
into test. This happens quite often so with svn we end up having to
do a lot of extra work to get the right things in the right places,
also theres the occasional spell rename, the scm ought to keep track
of the history through renames. Sorcery is a bit different in that we
have devel which can be one stream of code, and test/stable which can
be others.  We quite often fix something in test, then backport it to
devel. Also later devel gets merged into test. Of course theres also
the project branches which are spokes off of devel, devel gets pulled
into the project branches periodically, and then pushed back into devel
later. Its all quite complex, and we need the scm to think about it for
us if we're going to switch.

Hopefully I didnt bore everyone...

-Andrew


-- 
__________________________________________________________________________
|Andrew D. Stitt                           | astitt at sourcemage.org    |
|irc: afrayedknot                          | afrayedknot at t.armory.com |
|aim: thefrayedknot or iteratorplusplus    |                             |
|Sorcery Team Lead, Porting Team Lead      |                             |
|Grimoire Guru ham/smgl                    | ftp://t.armory.com          |
|Author and Maintainer of Prometheus       |                             |
--------------------------------------------------------------------------

Attachment: pgpZVxKcx7YBY.pgp
Description: PGP signature