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

[Emile Snyder]

On Wed, 2005-04-20 at 16:43, K. Richard Pixley wrote:
> 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.

Sorry, I thought you were saying that you thought that forcing
partitioning (what I took to mean working on different branches) was a
limitation of a tool; that better SCM systems should support you working
in this mode without forcing such a partitioning.

So, you're concerns about monotone scaling to this number of concurrent
developers are primarily about administrative/key management issues?  Or
something else?

> Emile Snyder wrote:
> > * who maintains them (branches)
> > 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?

Someone else gave a good cert answer to this.  It would be interesting
to sit down and try to think of all the hook implementations needed to
get what you're after here.

When you say you want to be able to "state and apply per branch
authorization mechanisms" what sort of things do you have in mind? 
Stuff like "only accept revisions on branch B if they're signed by a key
in this <set of branch committer keys>" ?  Do you mean on pull, so only
that stuff gets into your local db, or is it sufficient to do this on
checkout?

> > * 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.

So you have a repository with two projects (un-related branches),
com.yourcorp.ourproduct and com.yourcorp.localtool.  What do you mean
"too many connections"?  Until I got to that line I was thinking:

monotone --branch=com.yourcorp.localtool checkout t:4.5 LocalTool-4.5
cd LocalTool-4.5
make && make install
monotone --branch=com.yourcorp.ourproduct checkout t:0.2 OurProduct-0.2
cd OurProduct-0.2
./configure --with-localtool-dir=../LocalTool-4.5
make && make install

Do you mean that you want LocalTool to be a subdir (or subset of files
in) the OurProduct project, but to version them differently?  From an
organization standpoint, I would still want to have the two projects as
detailed above, and just checkout my localtool working dir as a
subdirectory of my ourproduct working dir.  I don't know how monotone is
with checking out another project into a subdirectory of a monotone
working dir... seems like something that should work, but I haven't
played with it.

> > * 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.

Huh.  So does clearcase store the files uncompressed, or index them as
you check them in, or what?  Curious about strategies to support this
functionality efficiently...

> So the next logical question, can I search the revision graph by
> revision content?  (Note that annotate won't find deleted text).

At the moment monotone doesn't really support searching the text of
historical versions at all.  You could do sql queries against the file
data, but as it's storing the head revision in full, but only xdeltas
back, you won't get text that is split across one of the deltas, for
instance.  And once you find the search string in a file or file_delta,
you still need to map it back out to revision(s).

> > > > 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
<snip>
> 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.

Huh.  Yeah, you can't get that info from monotone.  But, is it really
the useful info anyway?  Even if joe checked out branches foo, bar, and
baz I don't know if he's working on any of them.  Seems like knowing who
committed where is at least 90% of the useful info.  (And you can't
create a branch in monotone without committing to it; braches are the
collection of revisions with a given branch cert.)

> > 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?

monotone doesn't explicity handle directories at the moment, it just
makes them if their existence is implied by a file it's managing. 
There's various problems that this causes whose bug numbers I don't
recall off hand.

Apparently (although it's a bit over my head) the reworking to handle
them explicitly has some subtle issues.

thanks,
-emile

> --rich

+----------------------------------------------------------------------
If debugging is the process of removing bugs, then programming must be
the process of putting them in. -- Dykstra 
+----------------------------------------------------------------------

signature.asc
Description: This is a digitally signed message part