A.S. After toying with git some more, I revised the recommended instructions to follow the mirror(s)
apt-get install git-core git clone git://git.cuci.nl/pike cd pike git gc git branch -r # List available active remote branches # dead branches are available as # tags (like: 7.5 or ulpc.old) git checkout -f origin/7.7 git branch -f master # This creates your own development # branch called "master" # tracking official version 7.7 git checkout -f master git log master git log origin/7.7 git log origin/7.6 git log origin/7.4
Now edit around, and commit changes using:
git commit -a -m "Some useful one-line-description"
and repeat as often as needed (of course).
In order to update the mirror from upstream (my repository, where you cloned from), simply run:
git fetch
every once in a while. After doing so, perform:
git rebase origin/7.7
to actually move forward your own "master"-branch changes so they are automatically merged and (re)based onto the latest (official) updates from 7.7 Pushing back the changes into the official release involves using CVS (externally from git) still. The native git mechanisms cannot be used for that until the official repository is also changed to git.
The nice thing about git is that merges from the developmentbranch back into older stable branches are seemless and fully annotated. These advantages however, cannot be used until git is used natively. In theory, the merges could be retro-fitted into the branches, but there currently is no automated way of doing that to the existing tree (it can be done manually, git allows all kinds of "afterward fixing").
-------------------------------------
For Roxen/Caudium/Chilimoon, try the above with:
git clone git://git.cuci.nl/roxen git branch -r
Then pick either: origin/5.0 # for Roxen development branch origin/caudium # for Caudium development branch origin/chilimoon # for Chilimoon development branch
There are some places in the Pike code where CVS keyword substitution is used (like $Revision$ in Tools.pmod/Standalone.pmod/module.pike). In some cases, like this one, where those keywords are used outside of comments problems appear (doesnt compile). Any workarounds for git?
Also with this particular case (when the first constant is wrong), pike segfaults, apparently in f_function_name called by _sprintf in the last backtrace frame of that compile error.
best
arne
Arne Goedeke wrote:
There are some places in the Pike code where CVS keyword substitution is used (like $Revision$ in Tools.pmod/Standalone.pmod/module.pike). In some cases, like this one, where those keywords are used outside of comments problems appear (doesnt compile). Any workarounds for git?
I'm not quite sure how important the automatically visible version is in the places where it is currently used. It's not in a lot of places, it might be worth eliminating or creating a real workaround; however...
Also with this particular case (when the first constant is wrong), pike segfaults, apparently in f_function_name called by _sprintf in the last backtrace frame of that compile error.
In order to have something that works, I've created two branches (branches are really cheap in git; it's not unusual to create and delete two temporary branches a day):
git log origin/BuGless # My 7.7 branch which only holds the # patches on top of 7.7 which I # haven't checked into the master # CVS version yet.
git log origin/debian-be # The Debian Bleeding Edge version # I'm currently trying to maintain
Any thoughts about the $Revision$ dependencies?
I know that the fixes I checked into the BuGless branch are not real solutions, they just set it to static version-like strings (2.0); it should be carefully evaluated what the version number was intended to convey (and subsequently you can either drop it completely, or provide a good alternative). The reason why git doesn't endorse things like $Revision$ is because: - It needlessly clutters the diffs from revision to revision. - There is no such concept as the "revision number" in a (potentially) distributed revision control system as git (it *can* be centralised, though, and yes the numbers can still be generated, but it largely depends on what you really want to show).
On a related note, any objections against checking in the debian/ support tree into the master CVS?
On a related note, any objections against checking in the debian/ support tree into the master CVS?
Please go ahead; the added visibility of what happens there is a good thing, so everybody who knows Pike can help suggest what might be good and bad ways of following Debian's guidelines and the like (which at least led to a broken pike -x module in Debian earlier, at some time).
On Sun, Mar 09, 2008 at 12:13:37PM +0100, Stephen R. van den Berg wrote:
On a related note, any objections against checking in the debian/ support tree into the master CVS?
it already exists in packaging/debian/
greetings,martin.
On Sat, 8 Mar 2008, Arne Goedeke wrote:
Also with this particular case (when the first constant is wrong), pike segfaults, apparently in f_function_name called by _sprintf in the last backtrace frame of that compile error.
I looked into it again and the problem seems to be that in interpret.c:apply_low_safe_and_stupid() a dummy identifier_reference pointing to the first identifier is added to the program when trying to evaluate the constant expression. At that time however there are no identifiers in that program, yet. During the evaluation an error is thrown and f_function_name tries to access an uninitialized identifier pointed to by that reference.
Its possible to fix the segfault by changing use_dummy_reference to
int use_dummy_reference = !o->prog->num_identifier_references && o->prog->num_identifiers;
but I simply dont know if there are cases where that doesnt work.
arne
On Sat, 8 Mar 2008, Arne Goedeke wrote:
Also with this particular case (when the first constant is wrong), pike segfaults, apparently in f_function_name called by _sprintf in the last backtrace frame of that compile error.
I looked into it again and the problem seems to be that in interpret.c:apply_low_safe_and_stupid() a dummy identifier_reference pointing to the first identifier is added to the program when trying to evaluate the constant expression. At that time however there are no identifiers in that program, yet. During the evaluation an error is thrown and f_function_name tries to access an uninitialized identifier pointed to by that reference.
Its possible to fix the segfault by changing use_dummy_reference to
int use_dummy_reference = !o->prog->num_identifier_references && o->prog->num_identifiers;
but I simply dont know if there are cases where that doesnt work.
Thanks for the investigation; I've now implemented a tentative fix in Pike 7.7. My approach is to add a dummy identifier as well when the dummy reference is added. This ought to be safer. Please verify.
arne
On Wed, Mar 05, 2008 at 08:55:11PM +0100, Stephen R. van den Berg wrote:
git clone git://git.cuci.nl/pike
i took a look at this today and found some unusual commits:
8decc3071943c28c05a86eeeca8bb5d51b72f721 is a child of 0837b6c43da086c550776940fd6662a2122efb3a ae7f3204b059ab0597f93940b76179dea69e0531 is a child of f5f4cd09ef412671d5908073ae0a067844084801 f5f4cd09ef412671d5908073ae0a067844084801 has several strange children
greetings, martin.
pike-devel@lists.lysator.liu.se
-
Arne Goedeke -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum
-
Martin Bähr -
Stephen R. van den Berg