www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <santiago.g...@gmail.com>
Subject Re: [dSCM] Use case: infra down for maintenance
Date Fri, 02 May 2008 09:30:42 GMT
El vie, 02-05-2008 a las 03:56 -0400, Davanum Srinivas escribió:
> Hash: SHA1
> And the concrete proposal is? what?

No concrete proposal, this is intended for discussion of possible use
cases. Please notice the conditional verbal form. (Spanish has even more
of those "conditionals/subjunctive/..." forms than French) Very
specially, I don't want to put *any* stress on the infrastructure team
in moments where there are hardware problems, so please, infra people
reading these threads, just keep doing the cool and hard work and let
the threads for a moment where everything is going 100% right, etc.
Sorry if I disturbed you.

> Every project should have a wiki(?) which documents public repos which are sandboxes
of prople participating in the
> project (whether they are committers or folks submitting patches)

For folks submitting patches, I guess a URL would be enough, as in
"please pull a patch to do YYY from XXX". Other technique often used is
to have tools like git-format-patch/git-send-email, which will send a
series of emails for a set of commits. Those emails document 100% of the
changes, and can be applied by a different person while keeping
authorship and date info.

For committers, a centralized approach would have a repo per committer,
maybe with several branches, hanging off a place like git.kernel.org...
BTW, I have set up one at p.a.o/~sgala/git/ Please tell me if it is
supposed to be a problem, load or otherwise, or I should shut it down or
set up the appropriate robots.txt, ...

> And/OR
> When someone creates a JIRA, they should have an option to specify a public git repo
location and revision # for their
> patch.

If the patch is generated with something like git-format-patch, see for
it can be applied by git straight on, without loosing info (AFAICT). So
if we had a clever enough issue tracker stuff, the backoffice of JIRA
should recognize the format and offer a "merge" button, which would
automatically call git-svn on it... (magics happens) ...
Ditto for equivalent formats in mercurial, darcs, whatever... This is
just SciFi I guess. :)

OTOH, such a patch format allows me to save the patch and do something
git checkout master
git checkout -b SHINDIG-146-v3
git am /tmp/SHINDIG-146-for-humans-3.patch
gitk --all&

and have a colored diff browser for the patch, or 

git diff master SHINDIG-146-for-humans-3.patch

to see the squashed set of commits. The "for robots" versions just don't
use the move/copy detection, which makes them way more difficult to
read, as a lot of the changes are a rename +4 line changes... but able
to be applied with regular "patch". I actually applied one squashed
version of this one to subversion, but I could have applied the 48 small
changes series instead as 48 commits. The whole thing was an experiment.

I don't think we are at the stage of concrete proposals, at least until
the current problems are clearly solved. One good thing of the modern
SCM world is that changeset formats preserving most/all information are
being developed, so we can, in principle, have lots of interoperating
client sides.

Some people uses command line, some people emacs. Other people netbeans,
intelliJ or eclipse... it would be difficult to have a one-fits-all
solution. I guess the subversion repository format is the current lcd
(lowest common denominator). I like a lot Linus' solution for move-copy
management, very much metacrap-oriented
( http://www.well.com/~doctorow/metacrap.htm ). So I can reconstruct
moves and/or copies for visual inspection, even when subversion is not
tracking them because the author didn't properly move.

Compare this:
handled by svn as
Notice how git-svn told subversion about moves (as copy+delete)


I see:
handled as

i.e. even if the commit has no copy/move metadata, git reconstructs it,
vs  but viewvs doesn't know how. Had this commit gone through git-svn, we would have got better
metadata, and a smaller/more clever svn repo and diffs, assuming that the heuristics included
with git are good...

This is a killer, IMO. The algorithm for move/copy detection is tunable,
and very useful to review refactorings. In fact I'm currently reading
the foundation private  (or web site) repo changes in time by ignoring
completely commit emails and using just:

git svn rebase
git log --color-words --stat -p -M -C
(and then use "/^commit " to navigate commits in $PAGER)

which enables me to see typos corrected as red/green letters at the
terminal, for instance, and moved files like agendas -> minutes cleanly.
Saves a lot of cognitive effort, something nice for people getting old
as myself.

Those were part of the kind of things I wanted to talk about in the
proposal for ACUS 2008 I submitted about "accountancy of source code".


> thanks,
> dims
> Santiago Gala wrote:
> | El jue, 01-05-2008 a las 13:55 -0700, Doug Cutting escribió:
> |> Santiago Gala wrote:
> |>>> We do not want "peer to peer between developers" -- that is a violation
> |>>> our development methodology, not a tool limitation.
> |>>>
> |>> Please, define $We. I'm a member of the ASF, active in a few PMCs, and
> |>> have been an officer for some yers, and I don't feel included in such
> |>> $We.
> |> I think Noel meant that we want project work to take place in public, on
> |> mailing lists, in Jira and in Subversion.  Direct peer-to-peer exchanges
> |> of patches are not a matter of public record, and should thus not be
> |> encouraged as an Apache project development pattern.
> |
> | Peer to peer exchanges can, and possibly should be for this purpose,
> | done in public. See the hundreds of repos at http://git.kernel.org/ that
> | are variations on the "master" linus tree. They all, literally, document
> | work that would be sunk on private working copies at the ASF. Direct
> | peer-to-peer exchanges of patches is bazaar, not cathedral, style. But
> | neither cathedral style is public without taking measures for
> | transparency (we need to *require* public issue tracker, public lists,
> | no irc or logged irc, irc decisiones were a tough item a few years
> | ago...) nor bazaar style is private by default (in fact, the use of
> | "pull" promotes that every developer has at least one public clone to
> | allow access to their changes, or else they are forced to send patches).
> |
> | We should try to avoid framing the discussion into black/white
> | disjunctions. The line between
> |
> | a) using patches or quilt or eclipse "local changes" as "private repos"
> | and an issue tracker or a development list to review the work and commit
> | to svn, and
> | b) having a full fledged, mandatory dSCM setup for the ASF
> |
> | is a long line, full of places where people can stand. As Sander said,
> | as long as we have the master subversion repository documenting the
> | processes, one can use whatever is reasonable and interoperates with
> | issue tracking, patch generation and application, etc.
> |
> | Regards
> | Santiago
> |
> |> Doug
> Version: GnuPG v1.4.5 (Cygwin)
> AgtmLzK8XuJGkoPpD/5ENqs=
> =hr4E
Santiago Gala

View raw message