[Monotone-devel] is monotone for me?

[Andreas Jellinghaus]

Hi,

I'm looking for a rcs that will fit the way I want to work. maybe
some experienced monotone users can give me some hints, or tell
me what might be difficult with monotone?

Usualy I don't start new project, but rather change things on existing
projects. Because of that the foundation is either a tar file / freshly
extracted software, or a cvs repository available via anoncvs.

In short, I admire the way many linux kernel developers work, or used
to work, and want to try the same thing. Mostly that means gathering
whatever changes I did in one or several patch files, posting them
via ML so all developers can read and comment on them, and maybe
someone can accept them and merge them into the main development line.

I definitly don't like the cvs model of all developers having write
access with the usual problems of commit first, flame-war later.

So, what I want to do is download tar files, unpack, and inport those
tagged as version x.y.z. Or maintain a cvs tree, update it from time
to time, and import the result as version y-m-d.

Then usualy I do one or many, mostly small changes. The result I 
want to have and maintain is one or several patch files.

What I do with cvs, is chcking out the anon cvs tree twice as
app and app.orig, then do whatever changes I want in app and
test them a lot, then make distclean in app/ and create a diff
between app/ and app.orig/. The last step is cutting the diff
into several parts, usualy I send some of them as bug report,
and keep other, mostly experimental or unfinished parts for
myself.

That isn't that much work, and works more or less well. But
a lot of time is wasted, if I need to merge changes, then
again recreate the big diff, and split those changes again.

So I wonder if putting a rcs between the original unpacked
tars or cvs exports and my changed could help me to track
my changes. monotone has these pictures of left branch / right
branch and merge of both (any rcs has them :-).

I wonder if whenever I did some change, I could tell monotone:
this isolated change is a new branch. but my working copy
is a merge of one or several branches plus maybe some
uncommited work. Also when I update some change, I should
be able to tell that change is an update belonging to that
isolated branch.

Of course I know, if I change the same code, then extra
work will be able to put that into different branches,
or the second part needs to be a branch of the first part.
But that case is very rare. 

It might get tricky, if I change one file, and what the
differences in to different branches, but that should
be too hard (copy changed file, undo one half, commit
to a new branch, copy back full changes, commit the
rest ot a second new branch). Also updates to such
files could be some work, but I gues not much.

I hope that I could also gain more flexibility
with using a rcs - like removing the changes
in one branch from my work copy or create a
working copy with only the changes in some branches.
that would make testing more flexible.

the big question is, how hard it would be to
import a newly released upstream version, and
then port all branches to the new version?

in diff/patch style, that would be a rediff -
apply the patch, and diff again. no work at
all, unless some change in the new version
causes the apply to fail. but even then,
fixing isn't much work. managing the patches
is. that's why I'm looking for help, maybe
with monotone?

so, that's some idea I developed. Is it crazy?
impossible? hard? doable? maybe even easy with
monotone (or any other rcs)?

monotone like the other rcs systems focus on managing
sets of files, and diffs are the side product of that
work. While I actualy want to manage mostly diffs, and
different sets of files are the mere side product for
me. I wonder if monotone can still help me.

Regards, Andreas