From my point of view now would be a good time to split. Or, at least,
it doesn't look likely to get much better.
The recent yellow dots is due to a test case I added for a type check problem. I can disable that test again if it make things look bad..
So, opinions about splitting?
From my point of view now would be a good time to split. Or, at least, it doesn't look likely to get much better.
The recent yellow dots is due to a test case I added for a type check problem. I can disable that test again if it make things look bad..
I just added some code that should fix that case, it's however likely to trigg problems elsewhere.
So, opinions about splitting?
From my point of view now would be a good time to split. Or, at least, it doesn't look likely to get much better.
The recent yellow dots is due to a test case I added for a type check problem. I can disable that test again if it make things look bad..
I just added some code that should fix that case, it's however likely to trigg problems elsewhere.
Found a few more places that needed fixing, but it starts looking good.
So, opinions about splitting?
I'm waiting for the git repository with full backport info. Stephen?
How is the git repository relevant? We're not going to switch from cvs right here and now, are we? (Not that I personally would mind switching to git, though.)
Since a split can not be done in any good way with CVS, the plan was to switch to a better repository format (svn) before the next split.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Since a split can not be done in any good way with CVS, the plan was to switch to a better repository format (svn) before the next split.
I see. In that case I'll have a look and see what I can do to get the git repository up to a state which can compete with SVN on almost all levels. Give me 24 hours :-).
Well, you can start with fixing sequencial revision numbers, and a command line tool that doesn't need 500 flags to do the right thing... ;-)
I don't mean to fire up an old argument again, but is there a particular reason why moving to git rather than svn would be preferable that you couldn't get from git otherwise? There seem to be two distinct camps on this list, and they seem to be ignoring each other :)
If the repository is switched to svn, people can use git or svk or hg or whatever, but the reverse isn't necessarily true. Granted, there are flaws and shortcomings in svnland, and I'll be the first to admit it, but svn offers a lot more choice, and is still the de-facto standard when it comes to open source version control (assuming you're counting cvs out of the game).
What is the current plan? It seems to me that the long-time plan has been a move to svn, and I'm not convinced that git (or anything else right now for that matter) makes as much sense from a interop, user familiarity and stability standpoint. I'm not saying I'm 100% anti-git (though I personally prefer hg), just that right now, svn makes more sense as a central repository.
Bill
On Aug 11, 2008, at 11:35 AM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Since a split can not be done in any good way with CVS, the plan was to switch to a better repository format (svn) before the next split.
Xenofarm is relatively easy to whack into working atop a subversion repository (probably goes for a git repository as well); that is just a swift untangling it from fraternizing with the cvs browser.
For convenience, as that was a painstakingly slow operation in cvs, it asks http://pike.ida.liu.se/development/cvs/latest-Pike-7.<X>-commit for an UTC timestamp once in a while when it feels ready to generate a new build package, checks out the source tree matching corresponding timestamp (unless it felt it would be better to sit quietly waiting out quick fixes) with cvs -D, and that's all the integration there is to it.
(The files doing this are in pelix:~xenofarm/xenofarm_cvs, and to be quite precise, projects/pike/server*.pike, one matching each project.)
Getting the much less essential (though admittedly comfy) cvs browser up to par with the new repository reality won't happen as instantly, or will at least require some serious hackery to cater the different basic assumptions of whatever non-CVS/RCS version control system gets adopted instead as new world order.
With git, I presume the idea is that the command-line client replaces the comfy web UI, and those with a working X server setup get gitk too for snazzy visuals (I don't, at the moment, so I've only prodded at the less sexy command-line tools) on top.
With svn, it probably hurts a bit more, unless someone sets up Trac or similar, which has a fairly decent (if somewhat short of good) web UI of the same approximate type as the current breed of CVS browser. This stuff in practice needs us to change VCS backend before anyone will do it, as it's really boring work nobody got to doing while stuff worked.
All in all, Xenofarm can be up and running on whatever-else in no time (if proponent-of-whatever-else pokes at it for half an hour), and web visualization of commits (and checkin graph eye-candy on the pike site root page) will have a period of down time until someone puts in some love to that end.
(If threading seemed out of whack there, don't adjust your set; I just connected to something random, on the general discussion subject. :-)
On Mon, Aug 11, 2008 at 08:35:03PM +0000, Johan Sundstr�m (Achtung Liebe!) @ Pike (-) developers forum wrote:
web visualization of commits (and checkin graph eye-candy on the pike site root page) will have a period of down time until someone puts in some love to that end.
work on that end is held up by lack of access to the soon-to-be-released new version of the codelibrarian inside opera.
has that ever materialized somewhere? there was talk of putting it up on lysator, but i don't remember seeing the announcement of that actually happening. did it happen? url?
greetings, martin.
No, I guess that is partly my fault. I have the tarball that Martin Nilsson extracted from Opera and I should really comit it somewhere.
Shall we simply host it alongside the pike repository or put it on lys-cvs?
Marcus Agehall (Roxen IS) @ Pike (-) developers forum wrote:
No, I guess that is partly my fault. I have the tarball that Martin Nilsson extracted from Opera and I should really comit it somewhere.
Shall we simply host it alongside the pike repository or put it on lys-cvs?
Since it's not part of Pike as such, I suggest hosting it in lys-cvs.
for starters, just put the tarball as it is, somewhere to download. then import it into a repository where we can get write access to it.
greetings, martin.
hi markus,
did you get around to this yet?
if not, yould you please take care of it?
greetings, martin.
The Lysator CVS doesn't like me much at the moment, so I havn't taken care of it yet. But it's on my todo list.
On Mon, Sep 01, 2008 at 09:10:02AM +0000, Marcus Agehall (Roxen IS) @ Pike (-) developers forum wrote:
The Lysator CVS doesn't like me much at the moment, so I havn't taken care of it yet. But it's on my todo list.
maybe it's better to put it on pelix or the new server instead?
greetings, martin.
We sort of agreed it would make a harmless test object for git. So maybe Stephen can help with that?
is there an existing repository? or do we just have a snapshot without the previous history?
greetings, martin.
There is an internal repository at Opera, but I don't think they intend to release that one with all their internal modifications. (Nor do I want that to be honest...)
I have a snapshot from their repository which I've cleaned up a little bit and I think it should now be able to run both in a standard Roxen and in a vanilla Roxen CMS, without any modifications.
ah, ok, we'll have to live without history then. in that case it's easy as we just need to start a new branch.
if you put the archive somewhere to download, then i can take care of that.
is git installed on pelix? or is shell access available for pike-git.lysator.liu.se? (i don't want to drag the sources accross the globe if it can be done locally :-)
greetings, martin.
Peter Bortas @ Pike developers forum wrote:
We sort of agreed it would make a harmless test object for git. So maybe Stephen can help with that?
It can be checked into the pikex repository by anyone who has push access there. If you don't know how to get it in, tell me where the files are and I'll create a branch for it.
Oh boy..
The problem is that we neither are anywhere near a consensus on the way to go(*), nor have the supporting systems in place. Or do we?
I was hoping for a timeframe for a split this week, actually. And then I thought there can't be a whole lot of alternatives to do it traditionally with a cp -a in cvs, so that the xenofarm stuff and everything else on pelix keep chugging along.
Afterall, the mess can be sorted out afterwards in the exports to svn and git. It has been done before.
*) On that matter, all things considered, my vote is git: Local branches and stashes, offline repo, and cherry-picking are simply too good features to pass on. The rest are just details in comparison.
I was hoping for a timeframe for a split this week, actually.
So? Making a svn conversion takes less than 24 hours.
And then I thought there can't be a whole lot of alternatives to do it traditionally with a cp -a in cvs, so that the xenofarm stuff and everything else on pelix keep chugging along.
It seems that the only way to get "the xenofarm stuff and everything else" to ever get to work with anything else than CVS, is to do the switch regardless. Just announcing the plan, providing an example converted repository, and waiting for several years, apparently doesn't work.
Afterall, the mess can be sorted out afterwards in the exports to svn and git. It has been done before.
Yes, and it was a pain. Please don't inflict more.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Afterall, the mess can be sorted out afterwards in the exports to svn and git. It has been done before.
Yes, and it was a pain. Please don't inflict more.
Well, at the risk of sounding like an masochist, importing from svn/cvs into git was and isn't quite so painful as from cvs into svn (yes, I've done both).
On Mon, Aug 11, 2008 at 04:10:02PM +0000, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
I was hoping for a timeframe for a split this week, actually.
So? Making a svn conversion takes less than 24 hours.
and verifying that it is solid takes how long? (same argument for git btw, the conversion is done, but we are still busy verifying its correctness.)
It seems that the only way to get "the xenofarm stuff and everything else" to ever get to work with anything else than CVS, is to do the switch regardless.
good point, however it would be nice not to break xenofarm for the stable version, especially at a time when we are trying to stabilize and get a release out the door. once the release is made, the situation is a lot less critical
Afterall, the mess can be sorted out afterwards in the exports to svn and git. It has been done before.
Yes, and it was a pain. Please don't inflict more.
was the pain caused by lack of anticipating effects of making changes directly to the repo?
could the pain be avoided by making sure that the copies at split time remain identical, and only changes made are through regular commits?
greetings, martin.
and verifying that it is solid takes how long? (same argument for git btw, the conversion is done, but we are still busy verifying its correctness.)
Well, I have a 2 year head start with verifying the SVN repository. But I think that people need to start using the repos for it to be properly verified, and that just won't happen until it's the main repos.
good point, however it would be nice not to break xenofarm for the stable version, especially at a time when we are trying to stabilize and get a release out the door. once the release is made, the situation is a lot less critical
A compromise would be to keep the old repository active for the stable versions during a transition period, and make sure all changes are ported over between the repositories (maybe this can even be automated?).
was the pain caused by lack of anticipating effects of making changes directly to the repo?
could the pain be avoided by making sure that the copies at split time remain identical, and only changes made are through regular commits?
The major pains were caused by "cleanups" done in the repositories after the copy operations, yes. An identical copy with only new commits _should_ be only a minor pain, but I'm prepared to expect the unexpected....
On Mon, Aug 11, 2008 at 09:30:02PM +0000, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
A compromise would be to keep the old repository active for the stable versions during a transition period, and make sure all changes are ported over between the repositories (maybe this can even be automated?).
it can be (and already is) automated for git, since gits import is incremental. not sure about the cvs-svn import tool but i think that should have an option as well to specify where to start.
greetings, martin.
I can sympathize it feels sour that nothing has happened on that front for so long.
My concern is 7.8 right now. We at Roxen want it to be released RSN, and keeping xenofarm and the cvs repo running for it is important right after the release. I agree with the other Martin here that 7.9 is a whole other matter, and personally I wouldn't mind to not have a 7.9 repo at all until the migration is done.
Making a 7.8 the traditional way still requires an "mv 7.7 7.8" in the cvs repo, with whatever effects that has in the exports. At least this time we'd know the exact moment when it occurs.
Making a 7.8 the traditional way still requires an "mv 7.7 7.8" in the cvs repo, with whatever effects that has in the exports. At least this time we'd know the exact moment when it occurs.
As for the svn export, the name of the directory doesn't really matter (I just need to add a single line to the top level to use a different source path for that particular repos), so I'm fine with such a directory rename if we go for a "partial switch" plan.
i'd suggest to make a backup copy of the repo at switchpoint anyways, just in case something goes haywire. (which i doubt)
greetings, martin.
surely notafter every commit. what i meant was to have a copy of the exact split point that we want to use to start 7.9 from, not a random point nearby (whenever the backup happens)
greetings, martin.
The obvious thing to do is to leave the old repository online, but readonly, for reference.
On Mon, Aug 11, 2008 at 04:00:02PM +0000, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
I thought there can't be a whole lot of alternatives to do it traditionally with a cp -a in cvs, so that the xenofarm stuff and everything else on pelix keep chugging along.
i agree. forcing a repository switch before the split seems hasty. better get stable 7.8 out the door with the current system and work out the repo switch in the 7.9 timeframe.
greetings, martin.
i agree. forcing a repository switch before the split seems hasty. better get stable 7.8 out the door with the current system and work out the repo switch in the 7.9 timeframe.
If it didn't "work out" during the 7.7 timeframe, what makes you think that it will during the 7.9 timeframe? And what's "hasty" about a repository switch that's been in the works since 2006?
You think forcing a large amount of work onto all users of the Pike repository is a better method? I don't see why you need to link that to a new release. Updating all dependent tools need a stable and official new-style repository which, as others mention, can co-exist with the CVS repo for some time until the rest of the world catches up.
I vote against your suggestion.
You think forcing a large amount of work onto all users of the Pike repository is a better method?
I think it's necessary if that work is ever to be done. Otherwise we'll be stuck with CVS forever.
I don't see why you need to link that to a new release.
Well, apart from the fact that it ought to be linked to something to actually happen, it is linked to the split because making another bastard-split by copying the CVS repository will again increase the work needed to switch.
Updating all dependent tools need a stable and official new-style repository which, as others mention, can co-exist with the CVS repo for some time until the rest of the world catches up.
It has already existed for a long time. That apparently does not in itself actually change anything.
it is hasty in the sense that in the past weeks we have been focusing on a 7.8 release and not on a repository change.
i'd like to keep that focus now and do the split right after.
one problem as you accurately describe is that we have been waiting and nobody has been pushing to switch. now you are pushing, that is good. i am not saying that pushing is a bad idea, and i am not suggesting to wait for things to happen in the 7.9 timeframe. i agree, if we wait, 7.9 timeframe may not be much better.
but i am suggesting to hold off with that push just until after 7.8 is out or after the split.
how about: finish off 7.8 in cvs but don't even start 7.9 in cvs?
ie: don't make a cvs copy and make the split by switching without forcing 7.8 into the switch as well.
greetings, martin.
Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
The problem is that we neither are anywhere near a consensus on the way to go(*), nor have the supporting systems in place. Or do we?
I was hoping for a timeframe for a split this week, actually. And then I thought there can't be a whole lot of alternatives to do it traditionally with a cp -a in cvs, so that the xenofarm stuff and everything else on pelix keep chugging along.
Afterall, the mess can be sorted out afterwards in the exports to svn and git. It has been done before.
I was actually counting on a split using the old-and-proven CVS cp method, and that we actually switch repositories some time after that after all the dust has settled.
Because, indeed, waiting for the new repository (be it git or SVN or anything else) will not only delay things until is decided which way to move; but it will also stifle development because all tools need to be adjusted to the new repository before we can proceed.
So, in the spirit of Leisure Suit Larry: split early, split often.
From my point of view now would be a good time to split. Or, at least, it doesn't look likely to get much better.
The recent yellow dots is due to a test case I added for a type check problem. I can disable that test again if it make things look bad..
I just added some code that should fix that case, it's however likely to trigg problems elsewhere.
Found a few more places that needed fixing, but it starts looking good.
The dots are now turning green again.
So, opinions about splitting?
I'm waiting for the git repository with full backport info. Stephen?
Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
From my point of view now would be a good time to split. Or, at least, it doesn't look likely to get much better.
So, opinions about splitting?
All the things I care about are stable. So split++
No split until we can use SVN, but 7.7 is renamed 7.8 and I've tried to updated all tools and web pages.
Do a "find . -name Repository | xargs pike -x rsif Pike/7.7 Pike/7.8" in your checked out 7.7 trees.
Peter Bortas @ Pike developers forum wrote:
No split until we can use SVN, but 7.7 is renamed 7.8 and I've tried to updated all tools and web pages.
The xenofarm clients don't pickup the 7.8 build. Could there be a dangling devel link that needs to point to 7.8 somewhere?
We'll see. There are about 1 clients out there using the correct pike-devel and pike-stable URLs instead of the old pike-7.6/7.7. And it was only a short while ago I told the 7.7 mountpoint to serve up 7.8.
Peter Bortas @ Pike developers forum wrote:
We'll see. There are about 1 clients out there using the correct pike-devel and pike-stable URLs instead of the old pike-7.6/7.7. And
That's probably aristoteles, my client, setup fairly recently.
it was only a short while ago I told the 7.7 mountpoint to serve up 7.8.
Well, it doesn't seem to work, at least not for my client.
We'll see. There are about 1 clients out there using the correct pike-devel and pike-stable URLs instead of the old pike-7.6/7.7. And it was only a short while ago I told the 7.7 mountpoint to serve up 7.8.
I updated most (all?) of my Pikefarm clients a few hours ago, and some results should've appeared by now.
| Aug 12 16:11:26 Failed to send result. Resending in the next client run. | Aug 12 16:11:26 Project "Pike" failed with exit code 24 | Aug 12 16:11:26 FATAL: Failed to send result package to | http://pike.ida.liu.se/generated/pikefarm/packages/7.8/result!
It would also be nice if the 7.7 mountpoint came back so that the results for the last 7.7 builds could be reported:
| Aug 12 13:12:09 Failed to send result. Resending in the next client run. | Aug 12 13:12:09 Project "Pike" failed with exit code 24 | Aug 12 13:12:09 FATAL: Failed to send result package to http://pike.ida.liu.se/generated/pikefarm/packages/7.7/result! | Aug 12 14:35:29 Failed to send result. Resending in the next client run. | Aug 12 14:35:29 Project "Pike" failed with exit code 24 | Aug 12 14:35:29 FATAL: Failed to send result package to http://pike.ida.liu.se/generated/pikefarm/packages/7.7/result! | Aug 12 16:01:48 Failed to send result. Resending in the next client run. | Aug 12 16:01:48 Project "Pike" failed with exit code 24 | Aug 12 16:01:48 FATAL: Failed to send result package to http://pike.ida.liu.se/generated/pikefarm/packages/7.7/result!
I just downloaded the pikefarm archive. (Why is the 7.4 still in the config?)
Am I supposed to change anything (else)?
| Building project "Pike" from http://pike.ida.liu.se/generated/pikefarm/packages/devel/latest. | First test in this project. Preparing build environment. | Downloading Pike snapshot... | Running test "default" in pike-devel/iris/. | Uncompressing archive... | Extracting archive... | Building and running test "default": "make xenofarm" | *** glibc detected *** java: free(): invalid pointer: 0x000000004022afa0 *** | Sending results for "Pike": "default". | Host: pike.ida.liu.se | File: generated/pikefarm/packages/devel/result | Port: 80 | flen: 488449 | IP : 130.236.182.30 | Connecting...done | sending request..done | sending data..done | Reading reply... error 500: Internal Server Error. | Failed to send result. Resending in the next client run.
We'll see. There are about 1 clients out there using the correct pike-devel and pike-stable URLs instead of the old pike-7.6/7.7. And it was only a short while ago I told the 7.7 mountpoint to serve up 7.8.
I updated most (all?) of my Pikefarm clients a few hours ago, and some results should've appeared by now.
| Aug 12 16:11:26 Failed to send result. Resending in the next client run. | Aug 12 16:11:26 Project "Pike" failed with exit code 24 | Aug 12 16:11:26 FATAL: Failed to send result package to | http://pike.ida.liu.se/generated/pikefarm/packages/7.8/result!
There was a permission problem with the in/7.8 directory. I've fixed it, and now results for Pike 7.8 start turning up.
I would still like to have the results for Pike 7.7.
How would you like to have them? Should we move the results from the 7.7 database into the 7.8 database?
We can't have it both ways. Splitting without doing it in a new system will break the work that has been done to migrate.
Peter Bortas @ Pike developers forum wrote:
We can't have it both ways. Splitting without doing it in a new system will break the work that has been done to migrate.
I'm not quite sure I follow this. Tracking yet another CVS-split is a negligible amount of work in git, and should be not all that difficult in SVN either, or is it?
The svn converter actually compares the common parts of the repositores to find anomalies, with manually inserted clearingpoints for those anomalies I have inspected and reacted on. I hope you have a similar system for the git repository to scrutinize the information received from the CVS repositores (which can not be trusted as a matter of prinicple).
Another repository could theoretically lead to new anomalies which would affect the existing clearingpoint, but if no changes are done directly in the repository it _should_ not happen.
Besides, making a new CVS repository would remove the blowtorch to actually go through with the switch, meaning it will not happen for another 2 years again...
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
The svn converter actually compares the common parts of the repositores to find anomalies, with manually inserted clearingpoints for those anomalies I have inspected and reacted on. I hope you have a similar system for the git repository
Actually, what happened was that I did a clean *initial* import from your SVN repository, so anything you already fixed, is in my intial git import. After that, I proceded with imports from CVS, but only from their respective branches. I.e. I never pickup information from a CVS repository that refers to anything older than that CVS repository is valid for (e.g. I do not query a CVS repository for 7.6 for information other than versions 7.5 and 7.6, anything pertaining to 7.3 and 7.4 is obtained from the 7.4 repository).
to scrutinize the information received from the CVS repositores (which can not be trusted as a matter of prinicple).
Erm. Isn't it such that any checkout done from CVS from the (at the time) correct repository is the exact thing we're trying to replicate?
Another repository could theoretically lead to new anomalies which would affect the existing clearingpoint, but if no changes are done directly in the repository it _should_ not happen.
My point exactly.
Besides, making a new CVS repository would remove the blowtorch to actually go through with the switch, meaning it will not happen for another 2 years again...
I do think that everyone's ready for change now, so that will not be delayed by that long anymore.
Actually, what happened was that I did a clean *initial* import from your SVN repository, so anything you already fixed, is in my intial git import. After that, I proceded with imports from CVS, but only from their respective branches.
Ok, that should work provided the initial date is set sufficiently late.
Erm. Isn't it such that any checkout done from CVS from the (at the time) correct repository is the exact thing we're trying to replicate?
Nope. Sorry. Because things have been copied and renamed in the repository, a checkout from CVS of an old version might actually give you an incorrect result. Example: If you check out 7.7 from before 2005-10-18, you'll get a file lib/modules/Tools.pmod/Standalone.pmod/test_pike.pike. But that file did not actually exist with that name before 2005-10-18, so the result is wrong.
I do think that everyone's ready for change now, so that will not be delayed by that long anymore.
Great. Then we don't need a 7.9 repository in CVS. ;-)
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Erm. Isn't it such that any checkout done from CVS from the (at the time) correct repository is the exact thing we're trying to replicate?
Nope. Sorry. Because things have been copied and renamed in the repository, a checkout from CVS of an old version might actually give you an incorrect result. Example: If you check out 7.7 from before 2005-10-18, you'll get a file lib/modules/Tools.pmod/Standalone.pmod/test_pike.pike. But that file did not actually exist with that name before 2005-10-18, so the result is wrong.
Well, I knew that, which is why I said "at the time correct repository". In that case we're aiming for the same.
I do think that everyone's ready for change now, so that will not be delayed by that long anymore.
Great. Then we don't need a 7.9 repository in CVS. ;-)
Well, since it's so easy to setup, I see no harm in creating 7.9 for anyone dying to commit to 7.9 already. I personally am committed to fixing whatever still needs fixing in 7.8 first, no need to commit to 7.9 (I'll be doing that in my private (git)branches for the time being, if need be).
pike-devel@lists.lysator.liu.se
-
H. William Welliver III -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum
-
Jonas Walld�n ＠ Pike developers forum
-
Marcus Agehall (Roxen IS) ＠ Pike (-) developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Baehr -
Martin Bähr
-
Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum
-
Peter Bortas ＠ Pike developers forum
-
Stephen R. van den Berg