monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] newbie question - SHA1 vs serials


From: K. Richard Pixley
Subject: Re: [Monotone-devel] newbie question - SHA1 vs serials
Date: Wed, 20 Apr 2005 16:43:06 -0700
User-agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)

Emile Snyder wrote:
Can you clarify at all what sort of support an SCM could give you to let
you have > 128 concurrent developers on one branch all churning a given
file?
  
I wasn't necessarily thinking of them on the same branch.

Emile Snyder wrote:
These all seem like nice things, some of which maybe go better in a
higher level tool, like monotone-viz.  By points:
  
(feel free to assume knowing and agreeable nods on any points I've dropped.  :-)
* 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 ;)
  
I think this is a weakness.  In the same way that I want to be able to authorize changes using a more common authentication mechanism, I also want to be able to state and apply authorization mechanisms on a per-branch basis.

Can this be done with hooks now?
* 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.
  
Not missing anything.  Even queries on the revision graph or log files can provide a very useful overview.
* sandbox using pieces from different branches
hmmm.  at what granularity are the pieces of interest?   [...] care to elaborate?
  
Last week I released OurProduct-0.1 which was built using LocalTool-4.5.  Both are located in the same repository.  Yesterday I released OurProduct-0.2 which was built using LocalTool-4.6 and somehow, a bug got past all of our QA groups and reached the customer.  We suspect that the problem was introduced by LocalTool-4.6 so I'd like to try building OurProduct-0.2 with LocalTool-4.5 in order to compare it's behavior to yesterday's release.

Assume that LocalTool has so many connections to OurProduct that I can't just point a Makefile variable at another sandbox.
* grep the heads of all branches for given strings
this sort of stuff would be really nice.  nothing in monotone at the
moment.
  
In clearcase, this would probably be done by grep'ing against version extended pathnames.

So the next logical question, can I search the revision graph by revision content?  (Note that annotate won't find deleted text).
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.
  
In a central repository system, I have some indication of who's doing work, where, and how, from the patterns of their checkouts, branches they've created (but not yet commited to), etc.  The best I have with monotone is that someone sync'd.  I don't know who or where and the what is simply the entire repository, which isn't particularly indicative.
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.
Which piece is this?

--rich

reply via email to

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