Let me see
On Tue, Sep 2, 2014 at 2:49 PM, David Given <d...@cowlark.com> wrote:
> 1) C clones M's repository.
> 2) C does some work in multiple checkins.
> 3) C points the Magic Pull Request tool at a commit. This spits out a
> bundle containing everything that's needed to add that commit (and its
> ancestors) to M's repository.
> 4) C sends the bundle to M.
> 5) M adds the bundle to their repository (or a clone of their
> repository). All of C's changes end up in a private branch.
Alternatively, M always operates on a clone, obviating the need for
the private branch. It would just be a branch. ... Ok, it is less
secure given that M may forget to make the clone.
Maybe M should have a "Magic Pull Request Receiver Tool" as well, to
feed the bundle into; and it does all that (clone, import, ...)
> 6) M examines the changes, and either rejects them or merges them into
> trunk.
>
> None of this actually looks very hard. The trickiest part is step 3.
> Exporting the bundle is easy --- the git exporter is only 400 loc.
> Calculating what goes into the bundle is the only bit of interest, and
> even that's pretty straightforward:
>
> a) construct set of all ancestor commits from the nominated one
> b) subtract all commits in M's repository
> c) export commits remaining
>
> Pulling the commit graph from a local .fossil file looks pretty
> straightforward --- experimentation gives me this:
>
> SELECT parent.uuid, child.uuid
> FROM plink, blob AS parent, blob AS child
> WHERE child.rid = plink.cid AND parent.rid = plink.pid;
>
> (That seems way too easy, so I'm sure there's something I'm missing.)
>
> However, M's repository is *remote*, so I don't have direct access to
> its database.
> What's the easiest way to get the same information from a
> remote repository? It doesn't matter if it's hacky; I'd like to put
> together a proof-of-concept...
What your are proposing is actually a "sync over mail" with the
complicated part the detection of what M has and you therefore do not
have to send.
That information is part of a regular pull operation, so if we can
invoke only the steps to get that, without actually sending any
content back, then your new tool knows what the other side has.
More info on this in
http://fossil-scm.org/index.html/doc/tip/www/sync.wiki
Note that this requires digging into the fossil sources and extending
it with a command which runs the limited pull delivering the necessary
igot's from M to C, and printing the data for your tool.
--
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Faster™
F: 778.786.1133
andre...@activestate.com, http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/stackato
21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA --
http://www.tcl.tk/community/tcl2014/
Send mail to tclconfere...@googlegroups.com, by Sep 8
Registration is open.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
