7.8 blockers:
Owner Issue [/] Fallback to poll from epoll (from the conference road map). Implemented, but further testing is needed, as well as updated documentation. [ ] Fix gc of Stdio.File (from the conference road map). [ ] mast/zino New Windows build environment. [ ] per/marcus Performance regression --with-assembler. (per and marcus weren't present so item assigned without consent... per says memprotect() is responsible as far as -x benchmark goes.) [ ] zino/mast Building external modules should work. [ ] nilsson Write ChangeLog. [/] Module dumping should succeed for all modules. Currently it succeeds for all modules but 3: [ ] Tools.Standalone.dump [ ] Local [ ] Locale
Non-blockers:
[ ] jhs Build (SVG) graph from the -x benchmark results Pikefarm delivers to track development. [ ] An API for safely creating temporary files. Possibly wrapping mkstemp/mkdtemp.
If you think you could help with any of the items please do. Especially the items that have no one assigned to them yet.
7.8 blockers:
Owner Issue [/] Fallback to poll from epoll (from the conference road map). Implemented, but further testing is needed, as well as updated documentation. [ ] Fix gc of Stdio.File (from the conference road map). [ ] mast/zino New Windows build environment. [ ] per/marcus Performance regression --with-assembler. (per and marcus weren't present so item assigned without consent... per says memprotect() is responsible as far as -x benchmark goes.) [ ] zino/mast Building external modules should work. [ ] nilsson Write ChangeLog. [/] Module dumping should succeed for all modules. Currently it succeeds for all modules but 3: [ ] Tools.Standalone.dump [ ] Local [ ] Locale ! [ ] marcus Try to detect mismatching MySQL headers and libs ! in configure
Non-blockers:
[ ] jhs Build (SVG) graph from the -x benchmark results Pikefarm delivers to track development. [ ] An API for safely creating temporary files. Possibly wrapping mkstemp/mkdtemp.
If you think you could help with any of the items please do. Especially the items that have no one assigned to them yet.
7.8 blockers:
Owner Issue [/] Fallback to poll from epoll (from the conference road map). Implemented, but further testing is needed, as well as updated documentation. [ ] Fix gc of Stdio.File (from the conference road map). [ ] mast/zino New Windows build environment. [ ] per/marcus Performance regression --with-assembler. (per and marcus weren't present so item assigned without consent... per says memprotect() is responsible as far as -x benchmark goes.) [ ] zino/mast Building external modules should work. [ ] nilsson Write ChangeLog. [/] Module dumping should succeed for all modules. Currently it succeeds for all modules but 3: [ ] Tools.Standalone.dump [ ] Local [ ] Locale ! [ ] General dumping error: "Cannot encode overloaded ! functions (yet)." [ ] marcus Try to detect mismatching MySQL headers and libs in configure
Non-blockers:
[ ] jhs Build (SVG) graph from the -x benchmark results Pikefarm delivers to track development. [ ] An API for safely creating temporary files. Possibly wrapping mkstemp/mkdtemp.
If you think you could help with any of the items please do. Especially the items that have no one assigned to them yet.
7.8 blockers:
Owner Issue [/] Fallback to poll from epoll (from the conference road map). Implemented, but further testing is needed, as well as updated documentation. [ ] Fix gc of Stdio.File (from the conference road map). [ ] mast/zino New Windows build environment. [ ] per/marcus Performance regression --with-assembler. (per and marcus weren't present so item assigned without consent... per says memprotect() is responsible as far as -x benchmark goes.) [ ] zino/mast Building external modules should work. [ ] nilsson Write ChangeLog. [/] Module dumping should succeed for all modules. Currently it succeeds for all modules but 3: [ ] Tools.Standalone.dump [ ] Local [ ] Locale [ ] General dumping error: "Cannot encode overloaded ! functions (yet)." [ ] marcus Try to detect mismatching MySQL headers and libs in configure
Non-blockers:
[ ] jhs Build (SVG) graph from the -x benchmark results Pikefarm delivers to track development. [ ] An API for safely creating temporary files. Possibly wrapping mkstemp/mkdtemp. [ ] Update the Xenofarm package to current CVS.
If you think you could help with any of the items please do. Especially the items that have no one assigned to them yet.
7.8 blockers:
Owner Issue [/] Fallback to poll from epoll (from the conference road map). Implemented, but further testing is needed, as well as updated documentation. [ ] Fix gc of Stdio.File (from the conference road map). [ ] mast/zino New Windows build environment. [ ] per/marcus Performance regression --with-assembler. (per and marcus weren't present so item assigned without consent... per says memprotect() is responsible as far as -x benchmark goes.) [ ] zino/mast Building external modules should work. [ ] nilsson Write ChangeLog. [/] Module dumping should succeed for all modules. Currently it succeeds for all modules but 4: ! [ ] Int [ ] Tools.Standalone.dump [ ] Local [ ] Locale [ ] General dumping error: "Cannot encode overloaded functions (yet)." [ ] marcus Try to detect mismatching MySQL headers and libs in configure
Non-blockers:
[ ] jhs Build (SVG) graph from the -x benchmark results Pikefarm delivers to track development. [ ] An API for safely creating temporary files. Possibly wrapping mkstemp/mkdtemp. [ ] Update the Xenofarm package to current CVS.
If you think you could help with any of the items please do. Especially the items that have no one assigned to them yet.
7.8 blockers:
Owner Issue [/] Fallback to poll from epoll (from the conference road map). Implemented, but further testing is needed, as well as updated documentation. [ ] Fix gc of Stdio.File (from the conference road map). [ ] per/marcus Performance regression --with-assembler. (per and marcus weren't present so item assigned without consent... per says memprotect() is responsible as far as -x benchmark goes.) ! [ ] ageha/mast Building external modules should work. [ ] nilsson Write ChangeLog. [/] Module dumping should succeed for all modules. Currently it succeeds for all modules but 4: [ ] Int [ ] Tools.Standalone.dump [ ] Local [ ] Locale [ ] General dumping error: "Cannot encode overloaded functions (yet)." [ ] marcus Try to detect mismatching MySQL headers and libs in configure
Non-blockers:
[ ] jhs Build (SVG) graph from the -x benchmark results Pikefarm delivers to track development. [ ] An API for safely creating temporary files. Possibly wrapping mkstemp/mkdtemp. [ ] Update the Xenofarm package to current CVS. ! [/] mast/zino New Windows build environment.
If you think you could help with any of the items please do. Especially the items that have no one assigned to them yet.
7.8 blockers:
Owner Issue [/] Fallback to poll from epoll (from the conference road map). Implemented, but further testing is needed, as well as updated documentation. [ ] Fix gc of Stdio.File (from the conference road map). [ ] per/marcus Performance regression --with-assembler. (per and marcus weren't present so item assigned without consent... per says memprotect() is responsible as far as -x benchmark goes.) [ ] ageha/mast Building external modules should work. [ ] nilsson Write ChangeLog. [/] Module dumping should succeed for all modules. Currently it succeeds for all modules but 4: [ ] Int [ ] Tools.Standalone.dump [ ] Local [ ] Locale [ ] General dumping error: "Cannot encode overloaded functions (yet)." ! [X] marcus Try to detect mismatching MySQL headers and libs in configure
Non-blockers:
[ ] jhs Build (SVG) graph from the -x benchmark results Pikefarm delivers to track development. [ ] An API for safely creating temporary files. Possibly wrapping mkstemp/mkdtemp. [ ] Update the Xenofarm package to current CVS. [/] mast/zino New Windows build environment.
If you think you could help with any of the items please do. Especially the items that have no one assigned to them yet.
7.8 blockers:
Owner Issue [/] Fallback to poll from epoll (from the conference road map). Implemented, but further testing is needed, as well as updated documentation. [ ] Fix gc of Stdio.File (from the conference road map). ! [/] per/mast Performance regression --with-assembler. (per and marcus weren't present so item assigned without consent... per says memprotect() is responsible as far as -x benchmark goes.) [ ] ageha/mast Building external modules should work. [ ] nilsson Write ChangeLog. [/] Module dumping should succeed for all modules. Currently it succeeds for all modules but 4: [ ] Int [ ] Tools.Standalone.dump [ ] Local [ ] Locale [ ] General dumping error: "Cannot encode overloaded functions (yet)."
Non-blockers:
[ ] jhs Build (SVG) graph from the -x benchmark results Pikefarm delivers to track development. [ ] An API for safely creating temporary files. Possibly wrapping mkstemp/mkdtemp. [ ] Update the Xenofarm package to current CVS. [/] mast/zino New Windows build environment.
If you think you could help with any of the items please do. Especially the items that have no one assigned to them yet.
7.8 blockers:
Owner Issue [/] Fallback to poll from epoll (from the conference road map). Implemented, but further testing is needed, as well as updated documentation. [ ] Fix gc of Stdio.File (from the conference road map). [/] per/mast Performance regression --with-assembler. (per and marcus weren't present so item assigned without consent... per says memprotect() is responsible as far as -x benchmark goes.) [ ] ageha/mast Building external modules should work. [ ] nilsson Write ChangeLog. [/] Module dumping should succeed for all modules. Currently it succeeds for all modules but 4: [ ] Int [ ] Tools.Standalone.dump [ ] Local [ ] Locale [ ] General dumping error: "Cannot encode overloaded functions (yet)."
Non-blockers:
[ ] jhs Build (SVG) graph from the -x benchmark results Pikefarm delivers to track development. [ ] An API for safely creating temporary files. Possibly wrapping mkstemp/mkdtemp. ! [X] zino Update the Xenofarm package to current CVS. [/] mast/zino New Windows build environment.
If you think you could help with any of the items please do. Especially the items that have no one assigned to them yet.
7.8 blockers:
Owner Issue [/] Fallback to poll from epoll (from the conference road map). Implemented, but further testing is needed, as well as updated documentation. [ ] Fix gc of Stdio.File (from the conference road map). ! [X] per/mast Performance regression --with-assembler. (per and marcus weren't present so item assigned without consent... per says memprotect() is responsible as far as -x benchmark goes.) [X] markus Building external modules should work. [ ] nilsson Write ChangeLog. [/] Module dumping should succeed for all modules. Currently it succeeds for all modules but 4: [ ] Int [ ] Tools.Standalone.dump [ ] Local [ ] Locale [ ] General dumping error: "Cannot encode overloaded functions (yet)."
Non-blockers:
[ ] jhs Build (SVG) graph from the -x benchmark results Pikefarm delivers to track development. [ ] An API for safely creating temporary files. Possibly wrapping mkstemp/mkdtemp. [/] mast/zino New Windows build environment.
If you think you could help with any of the items please do. Especially the items that have no one assigned to them yet.
7.8 blockers:
Owner Issue [/] Fallback to poll from epoll (from the conference road map). Implemented, but further testing is needed, as well as updated documentation. ! [X] Fix gc of Stdio.File. *Working as intended, WONTFIX* [ ] nilsson Write ChangeLog. [/] Module dumping should succeed for all modules. Currently it succeeds for all modules but 4: [ ] Int [ ] Tools.Standalone.dump [ ] Local [ ] Locale [ ] General dumping error: "Cannot encode overloaded functions (yet)." ! [ ] zino Check status of Process.run() work.
Non-blockers:
[ ] jhs Build (SVG) graph from the -x benchmark results Pikefarm delivers to track development. [ ] An API for safely creating temporary files. Possibly wrapping mkstemp/mkdtemp. [/] mast/zino New Windows build environment.
If you think you could help with any of the items please do. Especially the items that have no one assigned to them yet.
! [X] Fix gc of Stdio.File. *Working as intended, WONTFIX*
I agree with this. It'd still be nice to remove the Fd_ref indirection so that callbacks in the Stdio.File don't count as cyclic refs (refs in an object to itself aren't counted since 7.6), but it's not something to do before the release.
7.8 blockers:
Owner Issue [/] Fallback to poll from epoll (from the conference road map). Implemented, but further testing is needed, as well as updated documentation. [ ] nilsson Write ChangeLog. ! [X] zino Allow modifiers->stdin to be a string in Process.run()
Non-blockers:
[ ] jhs Build (SVG) graph from the -x benchmark results Pikefarm delivers to track development. [ ] An API for safely creating temporary files. Possibly wrapping mkstemp/mkdtemp. [/] mast/zino New Windows build environment. ! [/] Module dumping should succeed for all modules. ! Currently it succeeds for all modules but 4: ! [ ] Int ! [ ] Tools.Standalone.dump ! [ ] Local ! [ ] Locale ! [ ] General dumping error: "Cannot encode overloaded ! functions (yet)."
If you think you could help with any of the items please do. Especially the items that have no one assigned to them yet.
7.8 blockers:
Owner Issue [/] Fallback to poll from epoll (from the conference road map). Implemented, but further testing is needed, as well as updated documentation. ! [ ] The backend behaves jerkily on IPv6 sockets on both ! Linux and Solaris. cf src/modules/files/socktest.pike ! with and without -DIPV6. [ ] nilsson Write ChangeLog. [X] zino Allow modifiers->stdin to be a string in Process.run()
Non-blockers:
[ ] jhs Build (SVG) graph from the -x benchmark results Pikefarm delivers to track development. [ ] An API for safely creating temporary files. Possibly wrapping mkstemp/mkdtemp. [/] mast/zino New Windows build environment. [/] Module dumping should succeed for all modules. Currently it succeeds for all modules but 4: [ ] Int [ ] Tools.Standalone.dump [ ] Local [ ] Locale [ ] General dumping error: "Cannot encode overloaded functions (yet)."
If you think you could help with any of the items please do. Especially the items that have no one assigned to them yet.
7.8 blockers:
Owner Issue [/] Fallback to poll from epoll (from the conference road map). Implemented, but further testing is needed, as well as updated documentation. ! [X] The backend behaves jerkily on IPv6 sockets on both ! Linux and Solaris. cf src/modules/files/socktest.pike ! with and without -DIPV6. Invalid; intentional behaviour ! for the test to avoid kernel bugs. [ ] nilsson Write ChangeLog. [X] zino Allow modifiers->stdin to be a string in Process.run()
Non-blockers:
[ ] jhs Build (SVG) graph from the -x benchmark results Pikefarm delivers to track development. [ ] An API for safely creating temporary files. Possibly wrapping mkstemp/mkdtemp. [/] mast/zino New Windows build environment. [/] Module dumping should succeed for all modules. Currently it succeeds for all modules but 4: [ ] Int [ ] Tools.Standalone.dump [ ] Local [ ] Locale [ ] General dumping error: "Cannot encode overloaded functions (yet)."
If you think you could help with any of the items please do. Especially the items that have no one assigned to them yet.
7.8 blockers:
Owner Issue [/] Fallback to poll from epoll (from the conference road map). Implemented, but further testing is needed, as well as updated documentation. ! [ ] The gc in some circumstanses loses track of num_objects, ! and fatals with "Object count wrong before gc". [X] The backend behaves jerkily on IPv6 sockets on both Linux and Solaris. cf src/modules/files/socktest.pike with and without -DIPV6. Invalid; intentional behaviour for the test to avoid kernel bugs. ! [X] grubba There was a buffer overrun in add_arrays(). [ ] nilsson Write ChangeLog. [X] zino Allow modifiers->stdin to be a string in Process.run()
Non-blockers:
[ ] jhs Build (SVG) graph from the -x benchmark results Pikefarm delivers to track development. [ ] An API for safely creating temporary files. Possibly wrapping mkstemp/mkdtemp. [/] mast/zino New Windows build environment. [/] Module dumping should succeed for all modules. Currently it succeeds for all modules but 4: [ ] Int [ ] Tools.Standalone.dump [ ] Local [ ] Locale [ ] General dumping error: "Cannot encode overloaded functions (yet)."
If you think you could help with any of the items please do. Especially the items that have no one assigned to them yet.
7.8 blockers:
Owner Issue [/] Fallback to poll from epoll (from the conference road map). Implemented, but further testing is needed, as well as updated documentation. ! [X] The gc in some circumstanses loses track of num_objects, ! and fatals with "Object count wrong before gc". [ ] nilsson Write ChangeLog. ! [ ] mast Fix quoting functions in Protocols.HTTP.
Non-blockers:
[ ] jhs Build (SVG) graph from the -x benchmark results Pikefarm delivers to track development. [ ] An API for safely creating temporary files. Possibly wrapping mkstemp/mkdtemp. [/] mast/zino New Windows build environment. [/] Module dumping should succeed for all modules. Currently it succeeds for all modules but 4: [ ] Int [ ] Tools.Standalone.dump [ ] Local [ ] Locale [ ] General dumping error: "Cannot encode overloaded functions (yet)."
If you think you could help with any of the items please do. Especially the items that have no one assigned to them yet.
Personally I'd rather see the split sometime after the release, to better focus efforts on stability. Is it that hard to just sit on all the code-wrecking fanciness for a while longer? (I have quite a lot of that myself, but not more than my five separate cvs trees can contain.)
Splitting is a way of trying to get it stable. Other methods I know of to contain everyone around here is to make the directory read only and tunnel all patches through one person that says no a lot. It has been the only way to divert people for the last 3 major releases.
There hasn't been a day for weeks when no one added features or fiddled around with code that is not technicly broken. Which is understandable because everyone want to get things in before release because we so seldom have releases. Which adds lots of work that contributes to having releases so seldom.
On Thu, Jul 24, 2008 at 11:50:02PM +0000, Peter Bortas @ Pike developers forum wrote:
Splitting is a way of trying to get it stable. Other methods I know of to contain everyone around here is to make the directory read only and tunnel all patches through one person that says no a lot. It has been the only way to divert people for the last 3 major releases.
well, the real problem here is that branching in cvs is hard, and merging even harder. time to improve the tools?
svn does not make merging much easier though. (but merge tracking in svn 1.5 should improves on that)
btw, if someone wants to use git to merge their work from the development branch into the stable branch, it's not necesary to have git on the server since you can do it locally and then just commit the result.
greetings, martin.
Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Personally I'd rather see the split sometime after the release, to better focus efforts on stability. Is it that hard to just sit on all the code-wrecking fanciness for a while longer? (I have quite a lot of that myself, but not more than my five separate cvs trees can contain.)
And in order to plug git a bit here, let me add that I do my own development on roughly three different branches locally in git, all contained inside of one tree on disk (I can switch branches using git quite easily), and for current development I tend to create a new branch which I then commit to several times, and then at the end, I merge all changes at once into CVS (and destroy my local development branch for this feature/bugfix).
Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Personally I'd rather see the split sometime after the release, to better focus efforts on stability. Is it that hard to just sit on all
Agreed; I'd prefer if the split was after the bugs found in the initial release were fixed. Backporting is tedious.
the code-wrecking fanciness for a while longer? (I have quite a lot of that myself, but not more than my five separate cvs trees can contain.)
And in order to plug git a bit here, let me add that I do my own development on roughly three different branches locally in git, all contained inside of one tree on disk (I can switch branches using git quite easily), and for current development I tend to create a new branch which I then commit to several times, and then at the end, I merge all changes at once into CVS (and destroy my local development branch for this feature/bugfix).
Speaking of git and backports, what's the current status of backport identification?
-- Sincerely, Stephen R. van den Berg.
But the release should be called "7.8", not "7.7", no? So instead of the tried and trusted splitting procedure
release1 release2 ---7.x+1---O------------O---------- / 7.x ----* \ ---7.x+2---
you are suggesting we do
release1 release2 ---7.x+1---O-----*------O---------- / \ 7.x ----' \ \ ---7.x+2------
this time?
Btw, backporting will be much simpler when we have a single svn repository, and can use "svn merge".
Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote:
Speaking of git and backports, what's the current status of backport identification?
I'm almost done with my pgsql lib, closing in on 100% performance of the old libpq postgres driver, possibly surpassing it. After that, the backport-identification project will make the final strides.
Yes, I find those git features very appealing. To have the complete repository always available locally is also a major feature.
So for me it's not at all clear that svn is the way to go in the future. But it depends a lot on how well these tools actually behaves in everyday use, and how well they integrate with the rest of the environment (Emacs, source browser, etc). I still have too little practical experience with either one to form an opinion on that (except I recall that annotate in svn was annoyingly slow when I tried it last, but that was two years ago).
Unless SVN develops into a DVCS it will be replaced eventually. But I'm not ready for one of the newfangled systems to be the base repository yet.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Does git handle renames with history?
If the whole file is renamed or moved in one commit, yes, always. If you delete the file first, then commit, then resurrect it in another place, then commit, no. If you move the file, alter the content, then commit, most of the time git gets it right.
Hm, so you can't merge contents from an older version of the same branch, only from the head of other branches?
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Hm, so you can't merge contents from an older version of the same branch, only from the head of other branches?
You can merge from any place, git doesn't impose restrictions there. Something tells me you misinterpret the implications of the three rename cases I listed before.
Well, you said a deleted file can't be resurrected with history? But it still exists with history in an earlier version, so that would imply that you can't copy it from there? Or does it mean that the history is lost when doing that?
git history is not per file but per changeset/branch. history of files exist only as part of the branch that contains the file.
to get the history of a file you ask for the branch history and filter for commits that change the file:
git log 7.7 -- somefile
if the file is deleted at some point and resurrected later then both parts of the history will show up unless it is resurrected under a different name (and deletion/resurrection don't happen in the same commit)
greetings, martin.
Ok, so git does not have the notion of pegged filenames then. But if I log the new filename, would I at least see in the entry for the resurrection commit what the original filename (and commit-id) was?
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Ok, so git does not have the notion of pegged filenames then. But if I log the new filename, would I at least see in the entry for the resurrection commit what the original filename (and commit-id) was?
Yes, you would.
And what about blame/annotate? If I query the author and commit-id for each line of the current version of the file (with the new filename), would I get accurate information from both before and after the resurrection?
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
And what about blame/annotate? If I query the author and commit-id for each line of the current version of the file (with the new filename), would I get accurate information from both before and after the resurrection?
Git has the information you want to see; I'm not completely certain what you mean by "accurate information", but the information is either shown already, or can be revealed with the proper options turned on.
With "accurate" I mean that the commit at which point the line was originally added is displayed, not the commit in which the file was resurrected (assuming the line was not changed as part of the resurrection, or later).
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
With "accurate" I mean that the commit at which point the line was originally added is displayed, not the commit in which the file was resurrected (assuming the line was not changed as part of the resurrection, or later).
That is already taken care of then. Git already does that accurately.
in git a branch is only the reference to its head. when you refer to an older commit, then git does not care which branch that comes from, all it will do is check if the commit you are trying to merge is already part of the branch. as such merging from an older version of the branch is a noop (everything is already merged, so what do you want to do?)
does your question relate to renaming?
greetings, martin.
Merging from an older version might not be a no-op, if you rolled back the change(s) in a later commit (for example by deleting the file). The question is related to brining back previously deleted files (in a new place; merging something into a new situation of course needs to take into acount that things may have been renamed), which was mentioned as a form of rename.
sorry, you are right, you would not use the git-merge command for that though (which deals with changesets only) but do git-checkout comitref -- filename
that's different from merging a changeset.
greetings, martin.
But would that allow you to commit the file in the new place, and retain its history? (Btw, would "filename" be the old filename or the new one? What do you do if they differ?)
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
But would that allow you to commit the file in the new place, and retain its history? (Btw, would "filename" be the old filename or the new one? What do you do if they differ?)
If you merge it from a place where the file existed before (as you normally would), then git retains a parent pointer to that older version, and hence has complete history/ancestry/annotation available.
But that place might not even exist anymore. Which is to say, the directory might have been deleted or renamed. So even if you could get around it by resurrecting it with the old name and immediately renaming it, that might simply not be possible.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
But that place might not even exist anymore. Which is to say, the directory might have been deleted or renamed. So even if you could get around it by resurrecting it with the old name and immediately renaming it, that might simply not be possible.
You are confusing things here. Files in git have a commit number (the SHA-1 belonging to the commit at the moment in time you are looking at) and a path (directory + filename).
E.g. consider the following commit:
commit f2542cf661424c58d8be8feb6baf37f26e221514 Author: Marcus Comstedt marcus@pike.ida.liu.se Date: Mon Jul 21 21:49:01 2008 +0000
Added fix to make libffi on Linux/PPC64 work with IBM JDK 1.6.0.1.
Any file in that commit can be referenced like: f2542cf:CHANGES f2542cf:src/svalue.c f2542cf:bundles/patches/libffi-3.0.4/src/powerpc/ffi.c
Now, at any point in time in the future, if you deleted the files and possibly their directories (some commits ago), you simply tell git to merge those files back in from the old f2542cf commit. It doesn't really matter where in the current tree you resurrect those files, as long as git has the merge-parent reference to f2542cf, it will know where the file(s) came from and will retain history, regardless of old and new locations in the tree.
So if I can resurrect f2542cf:bundles/patches/libffi-3.0.4/src/powerpc/ffi.c with any filename in any directory, even if "bundles" does not exist anymore, hat did you mean by "If you merge it from a place where the file existed before"? Can you give me an example of what it would mean to merge it from a place where the file did not exist before?
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
So if I can resurrect f2542cf:bundles/patches/libffi-3.0.4/src/powerpc/ffi.c with any filename in any directory, even if "bundles" does not exist anymore, hat did you mean by "If you merge it from a place where the file existed before"? Can you give me an example of what it would mean to merge it from a place where the file did not exist before?
Well, it wouldn't be a merge anymore. What you can do is simply pull the file out of thin air, and check it in again, without telling git that the original parent commit is f2542cf. In *that* case, since the immediately preceding commit didn't contain the file anymore (you deleted it a few commits ago), it doesn't know where to get the history.
Well, why would I deliberately withhold information that I would like the version control system to keep track of for me? That's a bit like saying "Sometimes git does not display log messages for commits", when that "sometimes" is the times when you didn't actually write any log message for the commit...
On Sun, Jul 27, 2008 at 12:04:42AM +0200, Stephen R. van den Berg wrote:
Now, at any point in time in the future, if you deleted the files and possibly their directories (some commits ago), you simply tell git to merge those files back in from the old f2542cf commit.
which command would you use for that? the git-merge command does not allowyou to pick filenames, the git-checkout command only gets the contents, but does not add anything to the commit.
greetings, martin.
Another (related) question: How about copies? If a new file is created from an existing file, and the original file also remains in the tree? This was for example the case when the README file in Pike was split into README and README-CVS. Can git handle that and retain a common ancestry for both files?
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Another (related) question: How about copies? If a new file is created from an existing file, and the original file also remains in the tree? This was for example the case when the README file in Pike was split into README and README-CVS. Can git handle that and retain a common ancestry for both files?
Yes. No problem whatsoever.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
How do you do it? I could not find any "git cp" command.
Simply copy the file using a normal "cp", then git add it, and git will pick it up automatically.
What will it do if there are two identical files which could have been the source? What if I make local changes before committing?
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
What will it do if there are two identical files which could have been the source? What if I make local changes before committing?
With two identical files it picks one as the source, but since both files share a common history, it doesn't matter which one he picks.
If you make local changes before committing, and your changes leave less than 50% of the original content, chances are that git will not show it to be a copy/rename anymore, however, git will *still* track history for the parts which are unmodified.
I didn't mean that the files have a common history, just identical contents. So if it just picks one, it might be the wrong one.
If I leave less than 50% of the contents, it seems even more likely that there may be multiple files with different history which have partial matches on the contents.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
I didn't mean that the files have a common history, just identical contents. So if it just picks one, it might be the wrong one.
This problem only arises if *both* files get renamed in the same commit. If only either one of those files is renamed in the same commit, history is retained.
If I leave less than 50% of the contents, it seems even more likely that there may be multiple files with different history which have partial matches on the contents.
In theory, yes. In practice, in code development projects, this problem rarely arises.
This problem only arises if *both* files get renamed in the same commit. If only either one of those files is renamed in the same commit, history is retained.
They didn't get renamed at all. I merely copied one of them.
In theory, yes. In practice, in code development projects, this problem rarely arises.
But can you fix it when it does?
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
This problem only arises if *both* files get renamed in the same commit. If only either one of those files is renamed in the same commit, history is retained.
They didn't get renamed at all. I merely copied one of them.
You mean: - You have two identical files in the repository. - Both files have a differing history. - The you copy one of those files, resulting in three identical files.
Yes, in that case, if the new name/directory seems closer to the "wrong" file, the history will be taken from the wrong file.
Then again, this is a very theoretical case, I've never seen this happen in practice; besides, if files end up being identical but with differing history, then in most cases, their history is related. It's rather unlikely that history is unrelated, but files end up identical.
In theory, yes. In practice, in code development projects, this problem rarely arises.
But can you fix it when it does?
The usual way to fix this was to fix the logic in git. The last time anyone had this problem and it needed to be fixed was more than a year ago.
Hints in the git repository could be generated to actually fix/prevent this problem, but for this to happen, the problem needs to become more common first; and it doesn't look very likely that it will occur a lot.
The identical file is pretty theoretical, yes. But if it tries to deduce origins of parts of files which were modified before commit, then it becomes more plausible. I noticed that you said that it "rarely" happens, rather than using a stronger term. :-)
Will you at least be able to see what guess git made before you commit? Although I'm not sure what you're supposed to do if you see that git guess wrong if you say that the only way to override the guess is to rewrite git...
On Sat, Jul 26, 2008 at 10:50:08PM +0000, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Will you at least be able to see what guess git made before you commit?
yes, it will tell you that it thinks you are copying a file, however that information is not actually recorded, but recalculated each time you read the log, therefore if the algorithm to detect copies is changed later, that change will apply to copies made in the past.
Although I'm not sure what you're supposed to do if you see that git guess wrong if you say that the only way to override the guess is to rewrite git...
right, i don't think you can do anything. but i think this whole case is rather unusual, can you construct an example where a problem would arise if the wrong copy is picked?
greetings, martin.
yes, it will tell you that it thinks you are copying a file, however that information is not actually recorded, but recalculated each time you read the log, therefore if the algorithm to detect copies is changed later, that change will apply to copies made in the past.
Hm, that sounds like a performance problem. You mean that each time one logs or annotates, it checks each add of the file against each other file in the tree to see if it might be a copy operation?
Also, I'm not entirely comfortable with the though that the history of an already committed file might spontanously change later.
right, i don't think you can do anything. but i think this whole case is rather unusual, can you construct an example where a problem would arise if the wrong copy is picked?
If it picks a file which just happens to have a few line which match, then those lines may have been written by a different person, at a different time, for a different purpose than the lines which were actually copied. That means that if you use blame to find the original author and ask him about the purpose, you'll get an incorrect answer. A line of code is not just a sequence of characters. It has an underlying purpose, within a context. Finding similarities without regarding context can be used to compress the repository, but not to infer parentship.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
yes, it will tell you that it thinks you are copying a file, however that information is not actually recorded, but recalculated each time you read the log, therefore if the algorithm to detect copies is changed later, that change will apply to copies made in the past.
Hm, that sounds like a performance problem. You mean that each time one logs or annotates, it checks each add of the file against each other file in the tree to see if it might be a copy operation?
It does this only when doing diffs or annotations, not when retrieving logs. No, it is not a performance problem because everything internally is hashed, i.e. it's not comparing large amounts of texts, it's comparing hashes mostly. Git diff and annotate are faster than SVN diff and annotate, the performance difference (in favour of git) even increases on deep histories.
Also, I'm not entirely comfortable with the though that the history of an already committed file might spontanously change later.
It doesn't. There are such things as regression tests, development and quality assurance on git is *very* active.
right, i don't think you can do anything. but i think this whole case is rather unusual, can you construct an example where a problem would arise if the wrong copy is picked?
If it picks a file which just happens to have a few line which match, then those lines may have been written by a different person, at a different time, for a different purpose than the lines which were actually copied. That means that if you use blame to find the original author and ask him about the purpose, you'll get an incorrect answer. A line of code is not just a sequence of characters. It has an underlying purpose, within a context. Finding similarities without regarding context can be used to compress the repository, but not to infer parentship.
True. But in order to make this a bit more concrete, can you actually think up a small example where this could happen and will pose a problem?
This problem has not been observed in the wild (by any git user), in the past two years or so, AFAIK.
It does this only when doing diffs or annotations, not when retrieving logs.
So the log will not show the original filename of a copy then, only for a "resurrection"? Can this be fixed by using the resurrection method (whatever it is) instead of regular cp to copy the file? I mean, you should be able to "resurrect" a file regardless of whether it was actually deleted in a later commit or not, and since you can "resurrect" it to a new filename, that would serve as a copy operation.
No, it is not a performance problem because everything internally is hashed, i.e. it's not comparing large amounts of texts, it's comparing hashes mostly.
Ok, now I'm confused. You previously implied that I could make local changes (up to 50%) before commit and it would still be recognized as a copy. That would mean that it has to compare more than just a hash.
Also, I'm not entirely comfortable with the though that the history of an already committed file might spontanously change later.
It doesn't. There are such things as regression tests, development and quality assurance on git is *very* active.
You said previously that the "usual" way to fix an incorrect guess was to change the logic in git, and that this had indeed happened. How does regression tests help if people are deliberately changing the behaviour?
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
It does this only when doing diffs or annotations, not when retrieving logs.
So the log will not show the original filename of a copy then, only for a "resurrection"? Can this be fixed by using the resurrection method (whatever it is) instead of regular cp to copy the file? I mean, you should be able to "resurrect" a file regardless of whether it was actually deleted in a later commit or not, and since you can "resurrect" it to a new filename, that would serve as a copy operation.
Maybe we should avoid getting lost in terminology. Maybe your idea of what a log is, and git's idea of what a log is differs. It might help to understand what git does, in essence, when committing. As a matter of fact, everytime you commit changes, what git basically do is the following:
a. Take a snapshot of the *entire* source tree (not just the changes). b. Take the SHA1-hash of the previous commit, and store it as the first parent of the current commit. c. Collect any other SHA1-hashes of other commits that is being merged from (regardless if they are part of the current branch, or not). d. Generate a new SHA1 for the current commit, which hashes all of the source-tree snapshot and collected parent SHA1s. e. Make the newly calculated SHA1 the head of the current branch.
In diff/annotate or other views of the history, all the copies are inferred from the full tree-snapshots and their parent relationships. The snapshots themselves do not carry information on which file went from where to where. Yet when you do git diff or git annotate or git blame, it will acurately and swiftly give you information on copied, renamed and moved files or pieces of source.
No, it is not a performance problem because everything internally is hashed, i.e. it's not comparing large amounts of texts, it's comparing hashes mostly.
Ok, now I'm confused. You previously implied that I could make local changes (up to 50%) before commit and it would still be recognized as a copy. That would mean that it has to compare more than just a hash.
Say you have a 30MB checked out source tree containing about 8000 files. Say you committed commit A, then copied one file, altered 40% of it, then commit it as commit B; whereas commit A is the parent of commit B. Then subsequently when you git diff A..B, git will look at both source-tree snapshots, will notice that in the first snapshot of 30MB it has 8000 files, in the second snapshot of 30MB it has 8001 files, it quickly compares hashes for all files, and figures out that 8000 files are identical, then knows for which file it is missing history. Then git begins to search for the new content, does partial hashes for chunks of the file, and searches through the partial hashes in the other files; possibly augmented by an algorithm which prefers files in the same directory or with similar names first. Then it tells you what it finds, and gives you the verdict that a file is a copy of, or just that chunks of the file appear in other files (and connects history there).
Also, I'm not entirely comfortable with the though that the history of an already committed file might spontanously change later.
It doesn't. There are such things as regression tests, development and quality assurance on git is *very* active.
You said previously that the "usual" way to fix an incorrect guess was to change the logic in git, and that this had indeed happened. How does regression tests help if people are deliberately changing the behaviour?
Bad matches are a rare event in practice. Whenever someone encounters it, improvements to the search and match algorithms in git can be offered for inclusion in mainstream git; the patches are only accepted if they do not cause mismatches in regressiontests which already exercise "cornercase" matches found and fixed earlier.
Say you have a 30MB checked out source tree containing about 8000 files. Say you committed commit A, then copied one file, altered 40% of it, then commit it as commit B; whereas commit A is the parent of commit B. Then subsequently when you git diff A..B, git will look at both source-tree snapshots, will notice that in the first snapshot of 30MB it has 8000 files, in the second snapshot of 30MB it has 8001 files, it quickly compares hashes for all files, and figures out that 8000 files are identical, then knows for which file it is missing history. Then git begins to search for the new content, does partial hashes for chunks of the file, and searches through the partial hashes in the other files; possibly augmented by an algorithm which prefers files in the same directory or with similar names first.
How much of a file is covered by each "partial hash"? It seems to me that even if only 40% of the file is changed, you might still get at least one changed byte in each part.
Bad matches are a rare event in practice. Whenever someone encounters it, improvements to the search and match algorithms in git can be offered for inclusion in mainstream git; the patches are only accepted if they do not cause mismatches in regressiontests which already exercise "cornercase" matches found and fixed earlier.
But it will cause mismatch (wrt previous logic) in some cases, otherwise it wouldn't fix the encountered problem. The fact that it doesn't change the behaviour for previously fixed cases doesn't mean that it doesn't change the behaviour for some cases which _didn't_ need fixing before.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
How much of a file is covered by each "partial hash"? It seems to me that even if only 40% of the file is changed, you might still get at least one changed byte in each part.
The algorithms are tuned to handle typical source files and corresponding changesets. In order to give an accurate answer I'd have to check the source of git a bit (even though I messed around with git source a bit, I haven't reviewed this part of the source yet).
But it will cause mismatch (wrt previous logic) in some cases, otherwise it wouldn't fix the encountered problem. The fact that it doesn't change the behaviour for previously fixed cases doesn't mean that it doesn't change the behaviour for some cases which _didn't_ need fixing before.
In theory yes, however, the algorithms involved are not that convoluted and quite straightforward, and they behave predictably when handling typical text-source-files (which is a lot easier than being predictable on *any* type of file), so changing them is not as chaotic as it seems, given enough sane reviewers checking the algorithm enhancements.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
The identical file is pretty theoretical, yes. But if it tries to deduce origins of parts of files which were modified before commit, then it becomes more plausible. I noticed that you said that it "rarely" happens, rather than using a stronger term. :-)
That's just my cautious me with words. "Rarely" in this case means, that it has not been observed yet, and is unlikely to be ever observed, yet does not have an absolute zero probability.
Will you at least be able to see what guess git made before you commit? Although I'm not sure what you're supposed to do if you see that git guess wrong if you say that the only way to override the guess is to rewrite git...
Git always stores correctly, since the repository doesn't record the guesses, as Martin explained.
Yes, in that case, if the new name/directory seems closer to the "wrong" file, the history will be taken from the wrong file.
Then again, this is a very theoretical case, I've never seen this happen in practice; besides, if files end up being identical but with differing history, then in most cases, their history is related. It's rather unlikely that history is unrelated, but files end up identical.
Wouldn't this be common for files like .cvsignore or similar files that contains a small set of rules that may exist in many instances throughout the source code?
Yes, in that case, if the new name/directory seems closer to the "wrong" file, the history will be taken from the wrong file.
Then again, this is a very theoretical case, I've never seen this happen in practice; besides, if files end up being identical but with differing history, then in most cases, their history is related. It's rather unlikely that history is unrelated, but files end up identical.
Wouldn't this be common for files like .cvsignore or similar files that contains a small set of rules that may exist in many instances throughout the source code?
Yes, but even then they've typically been copied if they have substantially the same content.
Note also that biasing towards regarding substantially similar files as copied would typically be safe, since the duplication of content is itself an indication that either the file has been copied, or its content is of trivial art (since it has been regenerated) and its history thus of limited interest.
for those the history would not be unrelated but most likely very similar
greetings, martin.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
How do you do it? I could not find any "git cp" command.
The only thing needed would be the following entry in your .gitconfig or /etc/gitconfig or in the repository .git/config:
[diff] renames = copies
If you don't have that, the rename/copy support might be less than expected.
7.8 blockers:
Owner Issue [/] Fallback to poll from epoll (from the conference road map). Implemented, but further testing is needed, as well as updated documentation. [ ] nilsson Write ChangeLog. [ ] mast Fix quoting functions in Protocols.HTTP.
Non-blockers:
[ ] Image.JPEG sometimes craches on 64bit (see 16706091) [ ] jhs Build (SVG) graph from the -x benchmark results Pikefarm delivers to track development. [ ] An API for safely creating temporary files. Possibly wrapping mkstemp/mkdtemp. [/] mast/zino New Windows build environment. [/] Module dumping should succeed for all modules. Currently it succeeds for all modules but 4: [ ] Int [ ] Tools.Standalone.dump [ ] Local [ ] Locale [ ] General dumping error: "Cannot encode overloaded functions (yet)."
If you think you could help with any of the items please do. Especially the items that have no one assigned to them yet.
7.8 blockers:
Owner Issue [/] Fallback to poll from epoll (from the conference road map). Implemented, but further testing is needed, as well as updated documentation. [ ] nilsson Write ChangeLog. ! [X] mast Fix quoting functions in Protocols.HTTP.
Non-blockers:
[ ] Image.JPEG sometimes craches on 64bit (see 16706091) [ ] jhs Build (SVG) graph from the -x benchmark results Pikefarm delivers to track development. [ ] An API for safely creating temporary files. Possibly wrapping mkstemp/mkdtemp. [/] mast/zino New Windows build environment. [/] Module dumping should succeed for all modules. Currently it succeeds for all modules but 4: [ ] Int [ ] Tools.Standalone.dump [ ] Local [ ] Locale [ ] General dumping error: "Cannot encode overloaded functions (yet)."
If you think you could help with any of the items please do. Especially the items that have no one assigned to them yet.
7.8 blockers:
Owner Issue [/] Fallback to poll from epoll (from the conference road map). Implemented, but further testing is needed, as well as updated documentation. [ ] nilsson Write ChangeLog. [ ] zino precompile.sh is installed with x-bits missing.
Non-blockers:
[ ] Image.JPEG sometimes craches on 64bit (see 16706091) [ ] jhs Build (SVG) graph from the -x benchmark results Pikefarm delivers to track development. [ ] An API for safely creating temporary files. Possibly wrapping mkstemp/mkdtemp. [/] mast/zino New Windows build environment. [/] Module dumping should succeed for all modules. Currently it succeeds for all modules but 4: [ ] Int [ ] Tools.Standalone.dump [ ] Local [ ] Locale [ ] General dumping error: "Cannot encode overloaded functions (yet)."
If you think you could help with any of the items please do. Especially the items that have no one assigned to them yet.
BTW: Do not interpret "nilsson" next to the changelog as a promise from him to do it any time soon. He is currently not avilable for this.
7.8 blockers:
Owner Issue [/] Fallback to poll from epoll (from the conference road map). Implemented, but further testing is needed, as well as updated documentation. [ ] nilsson Write ChangeLog. ! [X] zino precompile.sh is installed with x-bits missing. ! [ ] precompile.(sh|pike) is broken(?) See KOM 16706978.
Non-blockers:
[ ] Image.JPEG sometimes craches on 64bit (see 16706091) [ ] jhs Build (SVG) graph from the -x benchmark results Pikefarm delivers to track development. [ ] An API for safely creating temporary files. Possibly wrapping mkstemp/mkdtemp. [/] mast/zino New Windows build environment. [/] Module dumping should succeed for all modules. Currently it succeeds for all modules but 4: [ ] Int [ ] Tools.Standalone.dump [ ] Local [ ] Locale [ ] General dumping error: "Cannot encode overloaded functions (yet)."
If you think you could help with any of the items please do. Especially the items that have no one assigned to them yet.
pike-devel@lists.lysator.liu.se
-
Henrik Grubbstr�m (Lysator) ＠ 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
-
Per Hedbor () ＠ Pike (-) developers forum
-
Peter Bortas ＠ Pike developers forum
-
Stephen R. van den Berg