Re: [Dri-devel] merging to branches
On Sun, 5 Oct 2003 01:46:40 +0200 Felix Kühling [EMAIL PROTECTED] wrote: [snip] The -kk didn't seem to help at all (cvs up -kk -d -j HEAD). I still got C in 537 files. Same problems here. I'm trying to merge the trunk to the config branch. It is strange that cvs even attempts to merge files that I never committed any new revisions for on the branch. I also checked that I don't have any accidental local changes before I started. On some (many) of the files that I didn't change rcsmerge reports conflicts. I don't know what's going on. Is it a problem with my client or with the server? I can't imagine that this is normal CVS operation :-/ The fact that we're both having the same problems would point to the server. I'm working on a TCL script that resolves conflicts automatically. It just copies the new versions and discards the old ones. To be used on directories that you are sure were not changed on the branch. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] Felix Ok, the script is ready and seems to be working. It uses CVS/Entries files in order to traverse the working copy recursively considering only files that are in CVS. I don't have time to resolve my conflicts now. Anyway, maybe you want to try the script first ;-). The best procedure is probably to resolve the real conflicts and then have the script resolve the rest. BTW, 'grep -rlI *' gives me a count of 692 files with conflicts :-/ Regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. #!/usr/bin/tclsh proc resolveFile {filename} { set result [catch { set infile [open $filename r] } message] if {$result != 0} { puts stderr Can't open $filename for reading: $message return } set tmpname $filename.~tmp_resolve~ set result [catch { set outfile [open $tmpname w] } message] if {$result != 0} { puts stderr Can't open $tmpname for writing: $message close $infile return } set nConflicts 0 # states: # 0: normal text (copy) # 1: local (discard) # 2: new (copy) # 3: error (skip the whole file) set state 0 while {![eof $infile]} { set count [gets $infile line] if {$count == 0 [eof $infile]} { break } if {[string match * $line]} { if {$state == 0} { set state 1 continue } else { puts stderr $filename: Error: unexpected line: $line set state 3 break } } elseif {[string match === $line]} { if {$state == 1} { set state 2 continue } else { puts stderr $filename: Error: unexpected line: $line set state 3 break } } elseif {[string match * $line]} { if {$state == 2} { set state 0 incr nConflicts continue } else { puts stderr $filename: Error: unexpected line: $line set state 3 break } } if {$state != 1} { if {[eof $infile]} { puts -nonewline $outfile $line break } else { puts $outfile $line } } } close $infile close $outfile if {$state != 0 $state != 3} { puts stderr $filename: Error: there were unmatched conflict markers. set state 3 } if {$state == 3} { puts stderr $filename: Incomplete resolution left in $tmpname. return } if {$nConflicts 0} { puts stderr $filename: Resolved $nConflicts conflicts. file rename -force -- $tmpname $filename } else { file delete $tmpname } } proc resolveDir {dir} { if {[file exists $dir/CVS/Entries]} { set result [catch { set entries [open $dir/CVS/Entries r] } message] if {$result != 0} { puts stderr Can't open $dir/CVS/Entries: $message return } while {![eof $entries]} { set origEntry [gets $entries] set entry [split $origEntry /] if {[lindex $entry 0] == D} { if {[lindex $entry 1] != } { resolveDir $dir/[lindex $entry 1] } } elseif {[lindex $entry 0] == } { if {[lindex $entry 1] != } { resolveFile $dir/[lindex $entry 1] } } else { puts stderr Invalid entry: $origEntry } } close $entries } } resolveDir .
Re: [Dri-devel] merging to branches
On Fri, 3 Oct 2003 17:57:47 -0500 (CDT) [EMAIL PROTECTED] wrote: It would be good to have someone with hardware who could test the 4.2.0 libGL/savage_dri.so against the CVS DDX before and after a trunk merge to see if it breaks things. Unfortunately, from what I've been told now the savage card I have (an MX) won't work. I'll see if I can set up something like that. I would have to try and run an Xserver and savage DDX driver from the savage-1_0_0-branch with an old libGL and savage_dri.so. I would need to get Xfree86 4.2 sources and the original S3 code in order to compile a working 3D driver, right. That won't happen before some time next week. I have 4.2 sources and will try Rafael's patch with the savage branch, please explain me what test do you want done and I'll try to do it. I couldn't get the 4.2.0 dri drivers to work because my apps are linked against a newer libGL Thanks for the offer. Sounds like all you can do for now is test if the 2D driver works on your hardware. But what we really need to test is the 3D driver from S3 together with the 2D driver from S3 and the 2D driver merged from XFree86 CVS. In other words, we want to be sure that changes to the 2D driver don't break 3D. You could try to get 3D working with XFree 4.2 though. Generally it should be no problem to install a different libGL. What kind of errors do you get? Maybe libGL is installed in a different path on your system. What does ldd `which glxinfo` tell you? You can make sure that the XFree 4.2 libGL is used by pointing the environment variable LD_LIBRARY_PATH to the right directory. Regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] merging to branches
On Fri, 2003-10-03 at 13:55, Felix Kühling wrote: On Fri, 03 Oct 2003 12:14:32 -0700 Eric Anholt [EMAIL PROTECTED] wrote: Okay, I was going to merge trunk to the savage-1_0_0-branch, since updates to the savage driver in trunk help out with that work I've been Are you referring to the patch that Rafael Máximo sent yesterday? I was going to look at it, but I didn't have time yet. After a quick glance it looks like it reverts lots of changes S3 made to the driver. told. I went to the CvsPolicy wiki page and based on that did a tag on the savage branch of savage-1_0_0-trunk-premerge. Then I did cvs update -d -j HEAD. It ran for a while, and produced a large number of conflicts. Why should there be conflicts in files that weren't touched by the savage-branch? Is there a way to avoid having to deal with all of those? This is probably related to keyword substitutions. There is a node Merging and keywords in the CVS info documentation. Basically you should add -kk to the cvs update command line. This way keywords are not substituded and can't cause phantom conflicts. The -kk didn't seem to help at all (cvs up -kk -d -j HEAD). I still got C in 537 files. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] merging to branches
On Sat, 04 Oct 2003 16:02:53 -0700 Eric Anholt [EMAIL PROTECTED] wrote: On Fri, 2003-10-03 at 13:55, Felix Kühling wrote: On Fri, 03 Oct 2003 12:14:32 -0700 Eric Anholt [EMAIL PROTECTED] wrote: Okay, I was going to merge trunk to the savage-1_0_0-branch, since updates to the savage driver in trunk help out with that work I've been Are you referring to the patch that Rafael Máximo sent yesterday? I was going to look at it, but I didn't have time yet. After a quick glance it looks like it reverts lots of changes S3 made to the driver. told. I went to the CvsPolicy wiki page and based on that did a tag on the savage branch of savage-1_0_0-trunk-premerge. Then I did cvs update -d -j HEAD. It ran for a while, and produced a large number of conflicts. Why should there be conflicts in files that weren't touched by the savage-branch? Is there a way to avoid having to deal with all of those? This is probably related to keyword substitutions. There is a node Merging and keywords in the CVS info documentation. Basically you should add -kk to the cvs update command line. This way keywords are not substituded and can't cause phantom conflicts. The -kk didn't seem to help at all (cvs up -kk -d -j HEAD). I still got C in 537 files. Same problems here. I'm trying to merge the trunk to the config branch. It is strange that cvs even attempts to merge files that I never committed any new revisions for on the branch. I also checked that I don't have any accidental local changes before I started. On some (many) of the files that I didn't change rcsmerge reports conflicts. I don't know what's going on. Is it a problem with my client or with the server? I can't imagine that this is normal CVS operation :-/ The fact that we're both having the same problems would point to the server. I'm working on a TCL script that resolves conflicts automatically. It just copies the new versions and discards the old ones. To be used on directories that you are sure were not changed on the branch. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] merging to branches
Okay, I was going to merge trunk to the savage-1_0_0-branch, since updates to the savage driver in trunk help out with that work I've been told. I went to the CvsPolicy wiki page and based on that did a tag on the savage branch of savage-1_0_0-trunk-premerge. Then I did cvs update -d -j HEAD. It ran for a while, and produced a large number of conflicts. Why should there be conflicts in files that weren't touched by the savage-branch? Is there a way to avoid having to deal with all of those? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] merging to branches
FWIW, the 2D drivers from the trunk and the code drop from VIA are VERY different. I'm not sure where you are seeing the conflicts... just an FYI... --- Eric Anholt [EMAIL PROTECTED] wrote: Okay, I was going to merge trunk to the savage-1_0_0-branch, since updates to the savage driver in trunk help out with that work I've been told. I went to the CvsPolicy wiki page and based on that did a tag on the savage branch of savage-1_0_0-trunk-premerge. Then I did cvs update -d -j HEAD. It ran for a while, and produced a large number of conflicts. Why should there be conflicts in files that weren't touched by the savage-branch? Is there a way to avoid having to deal with all of those? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] merging to branches
On Fri, 03 Oct 2003 12:14:32 -0700 Eric Anholt [EMAIL PROTECTED] wrote: Okay, I was going to merge trunk to the savage-1_0_0-branch, since updates to the savage driver in trunk help out with that work I've been Are you referring to the patch that Rafael Máximo sent yesterday? I was going to look at it, but I didn't have time yet. After a quick glance it looks like it reverts lots of changes S3 made to the driver. told. I went to the CvsPolicy wiki page and based on that did a tag on the savage branch of savage-1_0_0-trunk-premerge. Then I did cvs update -d -j HEAD. It ran for a while, and produced a large number of conflicts. Why should there be conflicts in files that weren't touched by the savage-branch? Is there a way to avoid having to deal with all of those? This is probably related to keyword substitutions. There is a node Merging and keywords in the CVS info documentation. Basically you should add -kk to the cvs update command line. This way keywords are not substituded and can't cause phantom conflicts. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] Regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] merging to branches
On Fri, 2003-10-03 at 13:55, Felix Kühling wrote: On Fri, 03 Oct 2003 12:14:32 -0700 Eric Anholt [EMAIL PROTECTED] wrote: Okay, I was going to merge trunk to the savage-1_0_0-branch, since updates to the savage driver in trunk help out with that work I've been Are you referring to the patch that Rafael Máximo sent yesterday? I was going to look at it, but I didn't have time yet. After a quick glance it looks like it reverts lots of changes S3 made to the driver. That patch was based quite a bit on updates in XFree86 CVS from what I saw. I hadn't really looked at the 4.3.0 - S3 changes to compare how much the trunk merge changes would affect that code. But then, if it fixes basic 2d rendering problems, maybe we shouldn't worry too much about how it messes with the S3 changes for now. It would be good to have someone with hardware who could test the 4.2.0 libGL/savage_dri.so against the CVS DDX before and after a trunk merge to see if it breaks things. Unfortunately, from what I've been told now the savage card I have (an MX) won't work. told. I went to the CvsPolicy wiki page and based on that did a tag on the savage branch of savage-1_0_0-trunk-premerge. Then I did cvs update -d -j HEAD. It ran for a while, and produced a large number of conflicts. Why should there be conflicts in files that weren't touched by the savage-branch? Is there a way to avoid having to deal with all of those? This is probably related to keyword substitutions. There is a node Merging and keywords in the CVS info documentation. Basically you should add -kk to the cvs update command line. This way keywords are not substituded and can't cause phantom conflicts. Ahh, I'll give that a try. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] merging to branches
On Fri, 03 Oct 2003 14:28:50 -0700 Eric Anholt [EMAIL PROTECTED] wrote: On Fri, 2003-10-03 at 13:55, Felix Kühling wrote: On Fri, 03 Oct 2003 12:14:32 -0700 Eric Anholt [EMAIL PROTECTED] wrote: Okay, I was going to merge trunk to the savage-1_0_0-branch, since updates to the savage driver in trunk help out with that work I've been Are you referring to the patch that Rafael Máximo sent yesterday? I was going to look at it, but I didn't have time yet. After a quick glance it looks like it reverts lots of changes S3 made to the driver. That patch was based quite a bit on updates in XFree86 CVS from what I saw. I hadn't really looked at the 4.3.0 - S3 changes to compare how much the trunk merge changes would affect that code. But then, if it fixes basic 2d rendering problems, maybe we shouldn't worry too much about how it messes with the S3 changes for now. I agree. The only important changes are the ones that make the DDX driver DRI aware. We'll have to be careful not to mess up hardware locking. It would be good to have someone with hardware who could test the 4.2.0 libGL/savage_dri.so against the CVS DDX before and after a trunk merge to see if it breaks things. Unfortunately, from what I've been told now the savage card I have (an MX) won't work. I'll see if I can set up something like that. I would have to try and run an Xserver and savage DDX driver from the savage-1_0_0-branch with an old libGL and savage_dri.so. I would need to get Xfree86 4.2 sources and the original S3 code in order to compile a working 3D driver, right. That won't happen before some time next week. [snip] -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] merging to branches
It would be good to have someone with hardware who could test the 4.2.0 libGL/savage_dri.so against the CVS DDX before and after a trunk merge to see if it breaks things. Unfortunately, from what I've been told now the savage card I have (an MX) won't work. I'll see if I can set up something like that. I would have to try and run an Xserver and savage DDX driver from the savage-1_0_0-branch with an old libGL and savage_dri.so. I would need to get Xfree86 4.2 sources and the original S3 code in order to compile a working 3D driver, right. That won't happen before some time next week. I have 4.2 sources and will try Rafael's patch with the savage branch, please explain me what test do you want done and I'll try to do it. I couldn't get the 4.2.0 dri drivers to work because my apps are linked against a newer libGL --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel