|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:
I wasn't necessarily thinking of them on the same branch.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?
Emile Snyder wrote:
(feel free to assume knowing and agreeable nods on any points I've dropped. :-)These all seem like nice things, some of which maybe go better in a higher level tool, like monotone-viz. By points:
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.* 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 ;)
Can this be done with hooks now?
Not missing anything. Even queries on the revision graph or log files can provide a very useful overview.* 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.
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.* sandbox using pieces from different branches hmmm. at what granularity are the pieces of interest? [...] care to elaborate?
Assume that LocalTool has so many connections to OurProduct that I can't just point a Makefile variable at another sandbox.
In clearcase, this would probably be done by grep'ing against version extended pathnames.* grep the heads of all branches for given strings this sort of stuff would be really nice. nothing in monotone at the moment.
So the next logical question, can I search the revision graph by revision content? (Note that annotate won't find deleted text).
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.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.
Which piece is this?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.
|[Prev in Thread]||Current Thread||[Next in Thread]|