Folks,
Up until a few days ago, I was able to do this:
# vim some/wine/file.c # cvs diff some/wine/file.c > file.diff # mail wine-patches@winehq.com < file.diff # sleep <until Alexandre commited the patch> # cvs up
At this point, CVS would figure out that the changes in file.c in my tree are the same as the ones on the server, will give a message to that effect, and update the file.
As of lately, this no longer happens: I get a big fat conflic for all the changes I submit! This is *very* annoying. Anyone knows how to fix this behaviour? Alexandre, are you doing anything different?
As of lately, this no longer happens: I get a big fat conflic for all the changes I submit! This is *very* annoying. Anyone knows how to fix this behaviour? Alexandre, are you doing anything different?
Maybe automatic white-space stripping at commit time ?
Lionel
On September 6, 2002 05:16 pm, Lionel Ulmer wrote:
As of lately, this no longer happens: I get a big fat conflic for all the changes I submit! This is *very* annoying. Anyone knows how to fix this behaviour? Alexandre, are you doing anything different?
Maybe automatic white-space stripping at commit time ?
I was thinking of that, but I get a conflict on _every_ hunk... How can I avoid it, this is really, really bad. In particular, if I submit a large patch, and then I continue working on a different part of the file, I am in trouble...
-- Dimi.
Dimitrie O. Paun wrote:
On September 6, 2002 05:16 pm, Lionel Ulmer wrote:
As of lately, this no longer happens: I get a big fat conflic for all the changes I submit! This is *very* annoying. Anyone knows how to fix this behaviour? Alexandre, are you doing anything different?
Maybe automatic white-space stripping at commit time ?
I was thinking of that, but I get a conflict on _every_ hunk... How can I avoid it, this is really, really bad. In particular, if I submit a large patch, and then I continue working on a different part of the file, I am in trouble...
I got the same thing with the last patch I submitted. I don't know how long before the next time, so we'll see.
In any case, try leaving just the local part of a file you have not changed since the change, and do "cvs stat" on it. See if it is identified as "locally modified". If it is not, I would suspect something with your local cvs has changed.
Are you, by any chance, using Debain unstable, and doing apt-get dist-upgrade occasionally? Are you using cvsup to work with a local repository? The reson I am asking these questions is that these are the distinguishing charactaristics of my config that I could think that may affect this. If one of them is there, we can pretty much suspect that it is the curlpit.
Shachar
On September 6, 2002 06:33 pm, Shachar Shemesh wrote:
I got the same thing with the last patch I submitted. I don't know how long before the next time, so we'll see.
Aha! So I'm not alone...
In any case, try leaving just the local part of a file you have not changed since the change, and do "cvs stat" on it. See if it is identified as "locally modified". If it is not, I would suspect something with your local cvs has changed.
Of course it would be marked as "locally modified", because it is! If it wouldn't be, there would be no conflict.
Are you, by any chance, using Debain unstable, and doing apt-get dist-upgrade occasionally? Are you using cvsup to work with a local repository?
No, I use RH7.3. Yes, I use cvsup to update my local repository... Maybe that's the problem, but I don't see why it would be!
-- Dimi.
Le ven 06/09/2002 à 18:48, Dimitrie O. Paun a écrit :
On September 6, 2002 06:33 pm, Shachar Shemesh wrote:
I got the same thing with the last patch I submitted. I don't know how long before the next time, so we'll see.
Aha! So I'm not alone...
In any case, try leaving just the local part of a file you have not changed since the change, and do "cvs stat" on it. See if it is identified as "locally modified". If it is not, I would suspect something with your local cvs has changed.
Of course it would be marked as "locally modified", because it is! If it wouldn't be, there would be no conflict.
Are you, by any chance, using Debain unstable, and doing apt-get dist-upgrade occasionally? Are you using cvsup to work with a local repository?
No, I use RH7.3. Yes, I use cvsup to update my local repository... Maybe that's the problem, but I don't see why it would be!
-- Dimi.
It's probably very naive, but still... what does cvs diff from says? Or checking out in a fresh directory, and manually diffing both files? (Both from your local and the winehq.org repositery?)
Vincent
On September 6, 2002 07:13 pm, Vincent Béron wrote:
It's probably very naive, but still... what does cvs diff from says? Or checking out in a fresh directory, and manually diffing both files?
I have identified the problem: Alexandre is dropping the whitespace at the end of the line...
"Dimitrie O. Paun" dpaun@rogers.com writes:
I have identified the problem: Alexandre is dropping the whitespace at the end of the line...
Yes, now that whitespace has been cleaned up I've configured my Emacs to try to keep it that way. I don't want to receive a patch every day from the whitespace police <g>
On September 11, 2002 12:27 pm, Alexandre Julliard wrote:
Yes, now that whitespace has been cleaned up I've configured my Emacs to try to keep it that way.
That's not really obvious, and can screw people up... Not that people read docs, but maybe we should mention it in the "How to do a patch" bit? If you do a large patch, submit, and continue working, you're hosed!
"Dimitrie O. Paun" dpaun@rogers.com writes:
On September 11, 2002 12:27 pm, Alexandre Julliard wrote:
Yes, now that whitespace has been cleaned up I've configured my Emacs to try to keep it that way.
That's not really obvious, and can screw people up... Not that people read docs, but maybe we should mention it in the "How to do a patch" bit? If you do a large patch, submit, and continue working, you're hosed!
Well, I'm happy to turn it off if people consider it to be a problem. I just don't want to have people constantly submit patches to remove whitespace that others added with their patches; so we either decide that we all try to avoid trailing spaces, or we decide that nobody should care about it.
On September 11, 2002 12:58 pm, Alexandre Julliard wrote:
"Dimitrie O. Paun" dpaun@rogers.com writes:
Well, I'm happy to turn it off if people consider it to be a problem.
I think it should be turned off. It causes a lot of grief, for very little gain, if any. Moreover, now you have a tool in the tree that does that automatically, and cleverly.
If you think whitespaces are a problem, *you* apply it say, once a year. Or every 5 years, I don't care.
"Dimitrie O. Paun" dpaun@rogers.com writes:
I think it should be turned off. It causes a lot of grief, for very little gain, if any. Moreover, now you have a tool in the tree that does that automatically, and cleverly.
Well, that's precisely the point, the tool is only useful if the sources are reasonably clean to start with. Otherwise running the tool is going to create thousands of differences and that makes it useless. If some people use the tool then everybody has to use it, otherwise it's a constant fight between adding and removing spaces.
If you think whitespaces are a problem, *you* apply it say, once a year. Or every 5 years, I don't care.
Personally I don't think it's a problem at all. I'm happy to ignore trailing spaces and send all patches that attempt to remove them to /dev/null. Patrik may feel differently though <g>
On September 11, 2002 01:34 pm, Alexandre Julliard wrote:
Well, that's precisely the point, the tool is only useful if the sources are reasonably clean to start with. Otherwise running the tool is going to create thousands of differences and that makes it useless.
Not quite. If you run the tool on every commit (which is in effect what's happening now), you almost guarantee that many people contributing code will experience conflicts on a *daily* basis. If you run the tool once once a year, I will experience the conflict only then. And I will be so much happy.
I don't care if you run it once a year or never. But I do care quite a bit if you do it on every commit. If you can make other people happy by running it once in a while, so be it.
"Dimitrie O. Paun" dpaun@rogers.com writes:
Not quite. If you run the tool on every commit (which is in effect what's happening now), you almost guarantee that many people contributing code will experience conflicts on a *daily* basis. If you run the tool once once a year, I will experience the conflict only then. And I will be so much happy.
Well yes, that's what I meant by saying that the tool is "useless". If I'm the only one who can use it, and then only once a year, we don't really need it. And in fact we should probably remove it so that other people are not tempted to use it...
On September 11, 2002 01:51 pm, Alexandre Julliard wrote:
And in fact we should probably remove it so that other people are not tempted to use it...
As long as I don't have to deal with the conflicts. I had only grief from removing the whitespace, and NO benefit. For me, the choice is clear.
--- "Dimitrie O. Paun" dpaun@rogers.com wrote:
On September 11, 2002 12:58 pm, Alexandre Julliard wrote:
"Dimitrie O. Paun" dpaun@rogers.com writes:
Well, I'm happy to turn it off if people consider
it to be a problem.
I think it should be turned off. It causes a lot of grief, for very little gain, if any. Moreover, now you have a tool in the tree that does that automatically, and cleverly.
If you think whitespaces are a problem, *you* apply it say, once a year. Or every 5 years, I don't care.
I (personally) like to keep it the way it is. If the submitter is worried about the spaces he can run the whitespaces cleaning tool himself before submitting the patch (hint, hint ;-)
Andriy
__________________________________________________ Yahoo! - We Remember 9-11: A tribute to the more than 3,000 lives lost http://dir.remember.yahoo.com/tribute
Andriy Palamarchuk apa3a@yahoo.com writes:
I (personally) like to keep it the way it is. If the submitter is worried about the spaces he can run the whitespaces cleaning tool himself before submitting the patch (hint, hint ;-)
Well, no, if not everybody does it you can't do it either, otherwise it will create huge differences. I don't want to receive a patch that is 10% code and 90% whitespace changes just because the guy who edited the file before you didn't cleanup the spaces.
--- Alexandre Julliard julliard@winehq.com wrote:
Andriy Palamarchuk apa3a@yahoo.com writes:
I (personally) like to keep it the way it is. If the submitter is worried about the spaces he
can
run the whitespaces cleaning tool himself before submitting the patch (hint, hint ;-)
Well, no, if not everybody does it you can't do it either, otherwise it will create huge differences. I don't want to receive a patch that is 10% code and 90% whitespace changes just because the guy who edited the file before you didn't cleanup the spaces.
Hmm, I think I gave an impression opposite what I wanted.
Trying one more time: If the submitter is worried about the conflicts because of spaces he can run the whitespaces cleaning tool himself before submitting the patch (hint, hint ;-)
Andriy
__________________________________________________ Yahoo! - We Remember 9-11: A tribute to the more than 3,000 lives lost http://dir.remember.yahoo.com/tribute
On September 11, 2002 03:29 pm, Andriy Palamarchuk wrote:
Trying one more time: If the submitter is worried about the conflicts because of spaces he can run the whitespaces cleaning tool himself before submitting the patch (hint, hint ;-)
But then you end up the problem Alexandre was referring to! It's either all or nothing. Read his post again...
--- "Dimitrie O. Paun" dpaun@rogers.com wrote:
On September 11, 2002 03:29 pm, Andriy Palamarchuk wrote:
Trying one more time: If the submitter is worried about the conflicts because of spaces he can run the whitespaces
cleaning
tool himself before submitting the patch (hint, hint ;-)
But then you end up the problem Alexandre was referring to! It's either all or nothing. Read his post again...
As I see this one does not work either :-(
I agree with Alexandre. When we maintain "no-trailing whitespaces" policy developer has two options: a) to strip them with the tool or b) to resolve the conflicts
I'm for "no-trailing spaces" policy
Now I shut up, so I won't have to explain myself one more time.
Andriy
__________________________________________________ Yahoo! - We Remember 9-11: A tribute to the more than 3,000 lives lost http://dir.remember.yahoo.com/tribute
Alexandre Julliard wrote:
"Dimitrie O. Paun" dpaun@rogers.com writes:
On September 11, 2002 12:27 pm, Alexandre Julliard wrote:
Yes, now that whitespace has been cleaned up I've configured my Emacs to try to keep it that way.
That's not really obvious, and can screw people up... Not that people read docs, but maybe we should mention it in the "How to do a patch" bit? If you do a large patch, submit, and continue working, you're hosed!
Well, I'm happy to turn it off if people consider it to be a problem. I just don't want to have people constantly submit patches to remove whitespace that others added with their patches; so we either decide that we all try to avoid trailing spaces, or we decide that nobody should care about it.
Two solutions that come to mind: A. Commit the original patch immediatly followed by a commit to remove the white spaces (will not cause conflicts unless the same lines are changed after the commit). B. Add the "strip whitespaces at end" to the diff tool, and instruct people to use it.
Shachar
-
Alexandre Julliard -
Andriy Palamarchuk -
Dimitrie O. Paun -
Dimitrie O. Paun -
Lionel Ulmer -
Shachar Shemesh -
Vincent Béron