On Wed, 2005-04-20 at 12:30, K. Richard Pixley wrote:
I want to be able to determine how many branches exist, who created
them, who maintains them, what the common usages are, who's using
which, and typical code churn in each. I want to be able to determine
code pedigrees at a glance, merge status at a glance, I want to be
able to create a sandbox using bits from different branches and I want
to be able to grep the heads of all branches for particular strings.
How's that for a start?
These all seem like nice things, some of which maybe go better in a
higher level tool, like monotone-viz. By points:
* how many branches exist
monotone list branches | wc
* who created them
the easiest way to see this for monotone at the moment is to use
monotone-viz and have it show you either the branch of interest, or all
branches, and click the initial revision in the branch. it will then
show you the certs (including author) on that revision.
* who maintains them
no such "official" data in monotone. but if you have monotone-viz color
by author you can quickly see who's been doing the commits, which is (in
a non-pointy haired boss sense) potentially more useful ;)
* what the common usages are
not sure I understand, you mean why the branch was created? no such
official data in monotone, but you could easily have a policy of adding
a 'branch-reason' cert to the initial revision for branches which had
such an explanation.
* who's using them
see the "who maintains them" answer.
* typical code churn
hmmm. source metric reporting would be nice. at the moment I think
you'd have to write some scripts to do revision diffs to get that out;
not so nice. maybe i'm missing something.
* code pedigree at a glace
again, not exactly sure what you mean. monotone-viz again for
relationships between revisions. use the not yet implemented (although
i've been working on it) 'monotone annotate' for a given file to see
who's checked in a given piece of the code ;)
* merge status at a glance
monotone-viz all the way.
* sandbox using pieces from different branches
hmmm. at what granularity are the pieces of interest? the simplest
(and likely least what you want) is to create a new project.sandbox
branch, and do 'monotone propogate project.branchN project.sandbox' once
for each N, but that merges everything in branches 1..N and you said
pieces. if it's commit isolated changes, you can always use 'monotone
diff --branch=project.branchN --revision=rev1 --revision=rev2' | patch
in the sandbox, but you lose the info about where the patch came from
when you do the sandbox commit. care to elaborate?
* grep the heads of all branches for given strings
this sort of stuff would be really nice. nothing in monotone at the
moment.
experience, sorry.) How is the fact that someone might have a branch
that's not pushed to the canonical server different from the case where
a developer has some working dir that they haven't checked in at all
yet?
I may be confused. I was under the impression that all revisions
propogated to all repositories. So you're talking about a
geographical branch in the sense of a repository which simply hasn't
sync'd, yes?
You have a choice when you communicate with another repository whether
you only want to send changes (monotone push), recieve changes (monotone
pull), or both (monotone sync). You said that "In a distributed system,
I can't even ask what branches exist since no perspective is necessarily
even complete." This is true, but seems equivalent to saying "With
developers working on multiple machines I can't even ask what all the
current changes are, as they might not have checked them in yet." in a
centralized repository system. I was just wondering if I had missed
something that makes these two statements not equivalent.
I would hesitate to host large mission critical projects with monotone
just yet; seems like we're still working out quite a few kinks that
people who don't want to hack on monotone would be pretty annoyed with.
But it sure is progressing quickly ;)
Thanks. That's exactly what I've been trying to guage - how close,
how much work, how much time, etc. My current client may be willing
to accept some modest level of maintenance if basic stability is good.
Just my opinion (and I'm by no means the expert), but it seems to me
like the one really painful missing piece is the corrected directory
handling. All the other stuff that I've run into has been stuff like
CVS importing not having all the bugs shaken out yet. That and (for big
projects) the ongoing optimization work. Although that's been
progressing by leaps and bounds lately.
thanks,
-emile
--rich
+----------------------------------------------------------------------
RFC1925: "With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly
overhead."
+----------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
Monotone-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monotone-devel