Hmmm, sorry for the noise.
It seems that the debian package autoconf2.64 works. However somehow
deleting and installing autoconfxxx left a autoconf2.50 binary
installed, which the pike run_autoconfig script seems to prefers and
causes the error.
/Marc
Try an older autoconf version.
autoconf 2.13, autoconf 2.59 and autoconf 2.64 from debian packages all
produce the same error. Which one do you use?
Best regards,
Marc
Marc Dirix wrote:
I currently git this error with pike7.8 git head:
checking for sys/param.h... (cached) yes
/root/pike3/pike/src/modules/Image/configure: line 3380: syntax error
near unexpected token `;;'
/root/pike3/pike/src/modules/Image/configure: line 3380: `
ac_cv_path_GREP=$ac_path_GREP
are you planning to submit those fixes to git upstream?
it would be inconvenient to need a custom git implementation to make the
import script (or worse the repository) work well.
greetings, martin.
Peter Bortas @ Pike developers forum wrote:
The zone running the git and git-web services on eureka are down
until we figure out if git-web needs updating to fix some
vulnerabilities.
I can upgrade it to the latest version, no real pain there.
Or I could disabled git-web for the time being.
--
Peter Bortas @ Pike developers forum wrote:
The zone running the git and git-web services on eureka are down
until we figure out if git-web needs updating to fix some
vulnerabilities.
I can upgrade it to the latest version, no real pain there.
Or I could disabled git-web for the time being.
Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote:
Peter Bortas @ Pike developers forum wrote:
The zone running the git and git-web services on eureka are down
until we figure out if git-web needs updating to fix some
vulnerabilities.
I can upgrade it to the latest version, no real
zone booted up again.
Peter Bortas @ Pike developers forum wrote:
zone booted up again.
Thanks. Git (and gitweb) updated to version 1.6.2.103.gc4994 of
March 9th 2009.
--
Sincerely,
Stephen R. van den Berg.
Ping me harder!
The copyright statement says 1994, and the archived releases of LPC4 I
can find date from April 1994 to September 1994, so end of 1994 sounds
about right.
Helper script count_r2lines (counts total and original lines for a
particular path and revision):
--8--
#!/bin/sh
if [ $# != 2 ]; then
echo 2 Usage: $0 dir rev
exit 1
fi
dir=$1
rev=$2
repos=file://$HOME/repos/Pike/
hit=0
tot=0
svn ls -r$rev -R $reposPike/$dir@$rev | sed -e '/\/$/d' |
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Helper script count_r2lines (counts total and original lines for a
particular path and revision):
Does it disregard empty lines in the count?
--
Sincerely,
Stephen R. van den Berg.
There are three types of
Nope. Adapting the sed command to do that is left as an execercise.
:-)
a rough cut of the diagram is now here:
https://pike.ida.liu.se/development/history.xml
i'll leave beautification to the graphicians
i made this graph using git git diff --shortstat to compare all the
branches. 0.3b and 0.4 are included because there are some changes going
on that would otherwise
Infotastic! Would be interesting to space out the x axis according to
release times too, for yet another perspective on the data.
yes, i considered doing a similar graph that not only has the releases
but compares changes from month to month (or even week to week, given
one pixel width per week this should make for a nice graph :-)
greetings, martin.
I've now reconnected the history of ulpc(.old) to the main Pike
development line in the Subversion reposiotry, so if you do
svn log -v http://pike-svn.lysator.liu.se/Pike/7.8/src/pike_memory.c
you'll go al the way back to r2. :-) (Also, you can use blame to
find out that the hashstr()
it would be nice to get an overview of how much of the original code is
still left. maybe even for every version, to see the amount of change
happening.
greetings, martin.
Should be possible to find out with a script. I assume the
interresting metric would be how much of the current code is
original rather than how much of the original code is current?
both actually, while 10% of the current code being original means that
there is a lot of new code, it could be that 90% of the original code is
still current, which would means that most of the original code survived
but the whole codebase grew by a magnitude.
do that for each major revision and
Ok, the results are in:
7.8 7481 / 873478 0.9% 15.9%
7.6 7965 / 690785 1.2% 16.9%
7.4 8761 / 652559 1.3% 18.6%
7.2 11612 / 466609 2.5% 24.7%
7.0 12801 / 341128 3.8% 27.2%
0.6 15764 / 210659 7.5% 33.5%
0.5 20061 / 132486 15.1% 42.6%
ulpc
Oh, and there's 13 years and 1 month of development between ulpc.0
and today (ulpc.0 commit date was 1995-08-09).
very nice!
do we know the date when ulpc was started?
greetings, martin.
Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote:
The recommended practice is that for back/forwardports the commit id's
of the originating cherry-picked patches are mentioned at the bottom of
the new commit message.
Unfortunately that won't help (if we) in the future use git for
Correct. And apparently it was/is intended for merges only, even though
the diff-machinery already delivers correct results even if it's a
cherry-pick instead of a merge.
Does it? That's also a thing that confuses me: Consider commit
1cc21ef0320ecb734d4db5b85dbdc0406815e38e, which is a
On Tue, Sep 09, 2008 at 04:45:02PM +, Martin Stjernholm, Roxen IS @ Pike
developers forum wrote:
Btw, speaking of git-log, how does one make it print out the branches
like gitk does?
i think you are looking for
--decorate
Print out the ref names of any commits that
--decorate helps a bit, but it still doesn't show the branch(es) each
commit is made on. Thanks for the tip anyway.
Ok good, that should make the history more straight and simple.
Still, it would be nice if git had some builtin concept of
cherry-picked patches between branches, so it'd be possible to write
e.g. git log 7.6..7.8 to see all commits that really are in 7.8
only.
actually, there is a concept that could help, in addition to the normall
commit hash there is als an object hash that is only made out of the
diff and maybe the comment (not sure), now all that is needed is tools
to find multiple occurances of these and connect them.
that search could be
Like embee, I'm curious about those backport grafts that appear as
merges. Is this only a problem of representation in gitk and git-log?
To me it seems odd to describe them as merges since I reckon that
content would be identical after a merge.
I did some backchecks on the git mailinglist now,
true, but if the backport was done with a git cherry-pick they would
have at least the same author and timestamp. (ok, at that point one
might as well explicitly mark the cherry pick...)
greetings, martin.
Unfortunately that won't help (if we) in the future use git for
backports, since the new backports will get the same graphs once
again.
I don't understand this. What graphs?
I believe the problem lies in how gitk determines what branch(es) a
commit is on rather than on our use of grafts for
could you please post the commit ids?
greetings, martin.
Added DMALLOC_USE_HASHBASE mode is
fe982070cac0283b79a3a4a3a54b7865537acab7.
Also regarding src/pike_memory.c, its history starts with
memory.{c,h} renamed to pike_memory.{c,h}
(4e86f944a018c5397e3c55693b0637f63987e7d7). Regardless of -M, -C and
--find-copies-harder flags, I can't see the history
On Sat, Sep 06, 2008 at 12:40:02PM +, Martin Stjernholm, Roxen IS @ Pike
developers forum wrote:
Added DMALLOC_USE_HASHBASE mode is
fe982070cac0283b79a3a4a3a54b7865537acab7.
ah, i think i see the problem.
it looks like the backports somehow get indicated as whole merges.
not sure what
Martin Baehr wrote:
On Sat, Sep 06, 2008 at 12:40:02PM +, Martin Stjernholm, Roxen IS @ Pike
developers forum wrote:
Added DMALLOC_USE_HASHBASE mode is
fe982070cac0283b79a3a4a3a54b7865537acab7.
ah, i think i see the problem.
it looks like the backports somehow get indicated as whole
Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
More precisely, -F is the relevant flag. Unfortunately it doesn't work
with -c. I've bug reported that. Still I think I'd prefer to configure
git status to not use the pager at all.
There were elaborate discussions about this on the git
Stephen R. van den Berg wrote:
Stephen R. van den Berg wrote:
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
There should be a similar difference between
That should have read:
git blame README-CVS
git blame --find-copies-harder README-CVS
It turns out that git
Martin B?hr wrote:
On Mon, Jul 28, 2008 at 11:15:02PM +, Martin Stjernholm, Roxen IS @ Pike
developers forum wrote:
g. Anyone having local branches which are based off of commits in the
old git repository will have to rebase those
How do you go about that? Manually rebasing every
Same question. More mature in which way? Git is maturing at an amazing
rate (codebase wise), most open source projects either start with git or
move from CVS or SVN to git these days.
[citation needed] :-) What statistical material do you base this on?
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Same question. More mature in which way? Git is maturing at an amazing
rate (codebase wise), most open source projects either start with git or
move from CVS or SVN to git these days.
[citation needed] :-) What
On Tue, Jul 29, 2008 at 02:58:01PM +0200, Stephen R. van den Berg wrote:
- The percentage of people picking svn nowadays is roughly constant (after a
sharp drop as git came along).
that drop is actually in all packages, so i think it is just a case of
changing the counting
In any case, if
- Original Message
From: Stephen R. van den Berg [EMAIL PROTECTED]
To: pike-devel@lists.lysator.liu.se
Sent: Tuesday, July 29, 2008 8:58:01 AM
Subject: Re: Git
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Same question. More mature in which way? Git
Well, the user base of the tools doesn't necessarily reflect the
distribution of repository types among projects. There only has to be
one project which many are interrested in (say, the Linux kernel, a
project which would be of special interrest to users of a Linux
distibution such as Debian)
Lance Dillon wrote:
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Same question. More mature in which way? Git is maturing at an amazing
rate (codebase wise), most open source projects either start with git or
move from CVS or SVN to git these days.
[citation
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Well, the user base of the tools doesn't necessarily reflect the
distribution of repository types among projects. There only has to be
Very true.
The statistic shown is just that, a statistic, and since I don't have
The statistic shown is just that, a statistic, and since I don't have
any others, that's all I can show. I know it's just as bad as most
other statistics; the other information I have is even more vague than
this silly graph.
Fair enough. I was hoping for something more substantial since you
i think yes, and i think also ubuntu added it probably in april last
year (which would explain the sudden drop around that time)
greetings, martin.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
accidental wording. The part I have a hard time believing is that
most existing projects are switching to git. Even if a lot of
projects are, there are tons of open source projects. sourceforge
alone contains 290808
E.g. most GNU projects use git as their master repositories these days.
Is there some statistics on e.g. Savannah to support this?
I pulled up the list of official GNU projects on Savannah (349
projects), and manually checked the first 25.
CVS: 18
Git: 1
Both CVS and Git: 3
Both CVS and Svn: 1
No repository at savannah: 2
Still looks like CVS is in majority to me.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
E.g. most GNU projects use git as their master repositories these days.
Is there some statistics on e.g. Savannah to support this?
Well, same thing here, in this case when I say most, I actually mean
that I was looking
I also checked the latest 5 created official GNU projects:
CVS: 1
Both CVS and Mercurial: 1
Both CVS and Subversion: 2
Both CVS and git: 1
A closer race, but only one for git and two for svn... :-)
Am I the only one who thinks this discussion really belongs elsewhere?
Pros and cons about various VC systems as well as tutorials about
their command-line flags feels very off-topic to me.
Well, we can of course make the repository switch without prior
discussion. In that case I suppose we'd go a head with the (now
several years old) plan to switch to svn.
Well, same thing here, in this case when I say most, I actually mean
that I was looking at the page that lists the git projects, and most of the
core GNU tools I still remember from long ago were on it.
Ok, so you actually mean that most of the projects that use git are
GNU projects?
Looking at
Indeed.
Well, when facts which turn out to be unsubstantiated are brought
here, it seems appropriate to scrutinize them, no?
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Well, we can of course make the repository switch without prior
discussion. In that case I suppose we'd go a head with the (now
several years old) plan to switch to svn.
Switching to SVN is always better than
I see that the maintainer of diffutils is extra influential on you,
since you list his/her project twice. :-)
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
I see that the maintainer of diffutils is extra influential on you,
since you list his/her project twice. :-)
Must be a woman then :-).
Sorry, didn't notice that mistake until after sending.
--
Sincerely,
What? Last time I checked it did not have any version controlled meta
data handling at all.
more mature in what sense? if everyone uses git on the client side then
the maturity of svn on the server does not muy anything because you
still have to deal with git. it only adds hassle which wouldn't exist
otherwise.
Same question. More mature in which way? Git is maturing at an
On Tue, Jul 29, 2008 at 05:15:02PM +, Martin Stjernholm, Roxen IS @ Pike
developers forum wrote:
But it is as you say: It is maturing very fast, hence it's not mature
yet. I found several new and semi-essential features just by moving
from the latest Ubuntu package to the latest upstream
i was including the price to actually implement the change in the repo.
dump, edit, reload is way more expensive than fixing a comit and
rebasing.
greetings, martin.
Yes, but what was being talked about now was what people who had the
repository checked out had to do. The cost to implement the change in
the repo only has to be paid once, the cost to rebase needs to be paid
for each checked out tree.
just out of curiosity which features are those for you?
More subcommands to git-stash so that stashes actually get useful:
Earlier the only option was to clear all of them or nothing, which
means that one could only use them to very temporary things. Now I've
got 12 stashes with assorted small
On Tue, Jul 29, 2008 at 05:50:02PM +, Martin Stjernholm, Roxen IS @ Pike
developers forum wrote:
More subcommands to git-stash so that stashes actually get useful:
Earlier the only option was to clear all of them or nothing, which
means that one could only use them to very temporary
Since the discussion is for/prior to switching repository, I actually
do think it belongs in the developers forum... :p
It's a bit TLDR though, can we have an executive summary when you're
done?
Peter Bortas @ Pike developers forum wrote:
What? Last time I checked it did not have any version controlled meta
data handling at all.
True. Personally I don't miss it, keeping the metadata accurate usually
was more of a hassle than a feature to me (in SVN). I tended to create
rules to
Another note of interest (not necessarily my view, but interesting
enough to read, I'd think) with respect to metadata is:
http://plasmasturm.org/log/487/
He's got a point that it's a good concept to track content without
regard to the file that contains it, but that applies only to
Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
make me newer ubuntu packages. I took a look at fixing so that the
pager isn't used for short output though; it's annoying that git
status has started to use the pager too all the time.
Try:
LESS=-inqMSFXx4
in your environment (or a
Peter Bortas @ Pike developers forum wrote:
What? Last time I checked it did not have any version controlled meta
data handling at all.
Well, then it must be christmas :-)...
man gitattributes reveals version controlled data handling (version
controlled, because it is easily managed inside a
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Yes, but what was being talked about now was what people who had the
repository checked out had to do. The cost to implement the change in
the repo only has to be paid once, the cost to rebase needs to be paid
for each
That IS an improvement.
Try:
LESS=-inqMSFXx4
in your environment (or a suitable subset), it solves that problem.
More precisely, -F is the relevant flag. Unfortunately it doesn't work
with -c. I've bug reported that. Still I think I'd prefer to configure
git status to not use the pager at all.
It's not quite the
Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Same question. More mature in which way? Git is maturing at an amazing
rate (codebase wise), most open source projects either start with git or
move from CVS or SVN to git these days.
But it is as you say: It is maturing very fast,
On Mon, Jul 28, 2008 at 01:40:03PM +, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum wrote:
chiyo:/tmp/pike% git log --full-diff -M -C --until=1999-02-01
src/modules/_math commit abca4daf0d9e7fd4965f63e5dc45c3173cc74230
Merge: ab24694... c35e2fe...
Ok, but what
you hit a merge commit, for those the diff display is usually supressed,
you can get it with git show abca4daf0d9e7fd4965f63e5dc45c3173cc74230
I assume ++ in the diffs mean added with history? How do I see
where it is added from? The --- side is shown as /dev/null.
Also, that it should list
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Is this a result of misinterpreting the first CVS commit after the
split as the split itself? I think this should be fixed. I have a
list of good dates to insert synthetic commits for all the splits.
What is the point
Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Does the current export at srb's server correctly represent the
7.4/7.5/7.6/etc branches? I haven't been able to go back to e.g. the
7.6/7.7 split. Thought it would be possible using gitk.
That already is correct.
The branches are:
git branch -a --contains origin/HEAD
which branches origin/HEAD is contained in.
that means those branches are the same or newer than origin/HEAD from
there you can investigate further.
i usually just look at gitk to see the branch relationship.
greetings, martin.
The splits contain changes to the repository (renames and deletes)
which are not CVS commits but done directly in the cvsroot. So if you
check out 7.2 and 7.3 from immediately after the 7.1 split, they will
differ (7.2 will contain lib/modules/String.pmod, but 7.3 will contain
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
I think that, depending on how the git import script works, some
issues might actually disappear magically. But there are others
that won't. For example the fact that split points are not associated
with a CVS commit,
I have used the blessed SVN export as a base, but it still contained numerous
errors which I had to fix (some missing files, CR/LF mistakes *including* in
binary files).
It would be nice if you could report any such errors you find. Which
missing files, for example?
CR/LF mistakes might be due
It is possible to generate some kind of tree without resorting to GTK
applications?
On Mon, Jul 28, 2008 at 03:00:03PM +, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum wrote:
For example the fact that split points are not associated
with a CVS commit, so you have to fake one (something that the current
git import apparently doesn't).
because git
I have specifically and manually removed the fake split commits after
importing from SVN, because they didn't add information AFAICS.
Why would you want them in the repository?
They add the information about when the changes to the repository done
at the split were made. In the current git
gitk is tcl/tk
you can get an ascii tree using git log --graph,
everything else would involve graphics of some kind.
greetings, martin.
for git, a split does not become relevent until you actually make a
commit to the new branch,
Or when you change one of the destination repositories by other means
that making a commit. Which is what has happened at the split
points.
Thank you, that helped. Is there some way to collapse the view so that
only branches and their splits and merges are shown?
you can get an ascii tree using git log --graph,
I meant of the relationsships between all the branches. Wouldn't that
be git branch rather than git log?
Either way, neither log or branch seemed to recognize the --graph
option.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
The splits contain changes to the repository (renames and deletes)
which are not CVS commits but done directly in the cvsroot. So if you
check out 7.2 and 7.3 from immediately after the 7.1 split, they will
differ (7.2
On Mon, Jul 28, 2008 at 03:20:04PM +, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum wrote:
Well, that makes sense I guess. Btw, what is the difference (implied
by the convention) between master and HEAD?
master is just a default branch name and completely
On Mon, Jul 28, 2008 at 03:25:03PM +, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum wrote:
you can get an ascii tree using git log --graph,
I meant of the relationsships between all the branches. Wouldn't that
be git branch rather than git log?
sorry, you need of
then your version of git is to old.
--graph is a very new addition i believe in 1.5.6 (my version is 1.5.6.1)
1.5.4.3. I have an up-to-date Ubuntu Hardy Heron.
such a feature would be really nice indeed, but at the moment it does
not exist. i wonder how hard it would be to add it to gitk.
greetings, martin.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
then your version of git is to old.
--graph is a very new addition i believe in 1.5.6 (my version is 1.5.6.1)
1.5.4.3. I have an up-to-date Ubuntu Hardy Heron.
Try adding backports. I'm not quite sure where the
Try adding backports. I'm not quite sure where the latest version of
git is in ubuntu.
I have backports already. And intrepid has the same version as
hardy.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
I have used the blessed SVN export as a base, but it still contained numerous
errors which I had to fix (some missing files, CR/LF mistakes *including* in
binary files).
It would be nice if you could report any such
1 - 100 of 123 matches
Mail list logo
