On 11-12-07 01:35 PM, Hannes Magnusson wrote:
On Wed, Dec 7, 2011 at 22:01, Justin Martin<frozenf...@php.net> wrote:
On 11-12-07 11:46 AM, Hannes Magnusson wrote:
On Wed, Dec 7, 2011 at 18:09, Justin Martin<frozenf...@php.net> wrote:
On 11-12-07 02:58 AM, Hannes Magnusson wrote:
On Wed, Dec 7, 2011 at 01:57, Justin Martin<frozenf...@php.net>
wrote:
Hello everyone,
There's been some informal discussion in #php.doc on EFnet about how
the
transition from Subversion to Git will be achieved, and what the
resulting
structure will look like.
We can't use submodules.
Submodules in git reference a specific commit, not "last commit" like
it does in svn by default.
If we use git submodules in means;
Every time we update doc-base, you have to update the submodule in
_all_ translations to the last commit and commit the change.
-Hannes
Hi Hannes,
I was actually thinking of that issue, and thought that it would be a
simple
matter to use a client-side post-checkout hook to run "git submodules
foreach git pull". That'd update each submodule.
Not sure of the specifics in that regard, but I can't think of any other
solution to that problem than submodules.
Debugging client side post hooks is not something I want to even think
about when debugging why some translation doesn't work.
And, using this model, you would need to have 100 checkouts of
doc-base if you have 100 translations locally.
I would rather recommend that you simply have to do an explicit
doc-base checkout and update, not bundling.
Also, what worries me more is the way we determine if a file is
up2date or not. git doesn't have these sort of keywords and the idea
of bumping the files revision manually has been rejected several times
(although not in this context, the idea was to eliminate the
translators need to bump their version on english typo and ws fixes).
-Hannes
Hi Hannes,
There's not much difference between the way that Subversion does
svn:externals automatically, and scripting it with hooks in git. I mean, if
Sure there is. One is something you explicitly need to configure -
even before your first checkout, and the other "just works".
you do have a better idea, I'm definitely all-ears, because I've been
racking my brain for one. :P
Well, my first thoughts are
I would rather recommend that you simply have to do an explicit
doc-base checkout and update, not bundling.
that also solves the issue of having bucketloads of copies of the
exact same repo.
Not to mention no pre-configuration and trivial to debug.
As for doing svn:keywords, I've already pretty-well solved that.
https://github.com/TheFrozenFire/git-rcs-keywords
That's a fork of a solution which uses clean and smudge filters, which I've
modified from using Perl to using PHP. It's still in the works, but it's a
reasonable solution to a complicated problem.
This is just adding more and more prerequisites. Increasing the
difficulty to get up and running and more frustration and issues
debugging when it doesn't work for someone :(
-Hannes
Hi Hannes,
Submodules are cloned automatically. With a simple hook, they can be
updated on pull as well. That's almost exactly equivalent to the
subversion way; the only difference is that it's something we configure
explicitly. There's no increase in debugging that I can see.
Everyone who is working on the documentation should necessarily have PHP
installed. PHP (with pcre) is the only dependency that is added. It
could probably even be set up to simply *not* update those keywords if
PHP isn't available. No harm, no foul, the github version wouldn't know
any different. Since the keywords are being replaced client-side, rather
than server-side, and being reverted to their keyword form before the
data is sent, there's nothing that would ever break.
Those without PHP installed would still be able to edit the
documentation. They simply wouldn't see the replaced keywords. That
would only ever *possibly* be a problem for the translators, and it's a
fairly mild one at that.
Thanks,
Justin Martin
