Re: Code Reverting Itself
On Tue, Sep 25, 2012 at 04:21:48PM -0400, Kenny Raghunath wrote: > Hello, > > I'm having these strange issues when moving my code onto my production > environment. I start out by doing my PHP code within the trunk. When I'm > done, I merge my changes into a release branch and then deploy it via > Beanstalkapp to my staging environment. When I'm sure that the code is in > working order, I then deploy it manually via Beanstalkapp. Once the manual > deployment is complete, I verify my changes are on production and continue > working inside the trunk. Now, the strange part is that I get a phone call > from my client stating that the changes that I've done are not being shown. > When I go in and check the code, it's not there anymore. When I do the > deployment a second time, the changes are shown to be correct again and > this time, it sticks. I'm not sure if this has to do something with > Subversion or the fact that I'm using Beanstalkapp to move my code around, > but this one is the most recent one. > Another instance of my code reverting itself would be when I was doing > changes to my trunk and I'm doing micro-commits. I've noticed that the > changes that I have been doing were there, but some changes aren't. For > example, I was editing fileA.php for a few commits. I wouldn't see the > changes I've made two revisions ago, but I'd see changes that I've made at > the current revision. It seemed like my code was mixing itself up for some > reason. Anyone have any suggestions on what I can do to fix this? > > Thanks! A common problem case is: - You have a versioned file open in an editor. - You run 'svn update' and the file receives changes from the repository. - The editor doesn't notice the file has been changed on disk, so the changes brought in by the update are not reflected in the editor window. - You save from the editor, overwriting changes brought in during the update. - You commit the current state without checking that what you're committing is really what you intend to commit, undoing already committed changes. I suspect you're running into some variant of this problem. The usual workaround is to get a smarter editor, or close the editor before running 'svn update'. You should review the changes which were actually committed to find out what happened. In Subversion 1.7 you can run svn log --diff on a file which had changes undone accidentally. Then check each diff for changes that are unrelated to what was supposed to be committed. Maybe that will help you with pinpointing the cause of the problem.
Re: Code Reverting Itself
Nico Kadel-Garcia Email: nico.ka...@tufts.edu Sent from iPhone On Sep 26, 2012, at 5:59, Stefan Sperling wrote: > On Tue, Sep 25, 2012 at 04:21:48PM -0400, Kenny Raghunath wrote: >> Hello, >> >> I'm having these strange issues when moving my code onto my production >> environment. I start out by doing my PHP code within the trunk. When I'm >> done, I merge my changes into a release branch and then deploy it via >> Beanstalkapp to my staging environment. When I'm sure that the code is in >> working order, I then deploy it manually via Beanstalkapp. Once the manual >> deployment is complete, I verify my changes are on production and continue >> working inside the trunk. Now, the strange part is that I get a phone call >> from my client stating that the changes that I've done are not being shown. >> When I go in and check the code, it's not there anymore. When I do the >> deployment a second time, the changes are shown to be correct again and >> this time, it sticks. I'm not sure if this has to do something with >> Subversion or the fact that I'm using Beanstalkapp to move my code around, >> but this one is the most recent one. >> Another instance of my code reverting itself would be when I was doing >> changes to my trunk and I'm doing micro-commits. I've noticed that the >> changes that I have been doing were there, but some changes aren't. For >> example, I was editing fileA.php for a few commits. I wouldn't see the >> changes I've made two revisions ago, but I'd see changes that I've made at >> the current revision. It seemed like my code was mixing itself up for some >> reason. Anyone have any suggestions on what I can do to fix this? >> >> Thanks! > > A common problem case is: > > - You have a versioned file open in an editor. Oh, lord, that one is common. It's aggravated > - You run 'svn update' and the file receives changes from the repository. > - The editor doesn't notice the file has been changed on disk, so the > changes brought in by the update are not reflected in the editor window. > - You save from the editor, overwriting changes brought in during the update. > - You commit the current state without checking that what you're > committing is really what you intend to commit, undoing already > committed changes. > > I suspect you're running into some variant of this problem. > The usual workaround is to get a smarter editor, or close the editor > before running 'svn update'. > > You should review the changes which were actually committed to find out > what happened. In Subversion 1.7 you can run > svn log --diff > on a file which had changes undone accidentally. Then check each diff > for changes that are unrelated to what was supposed to be committed. > Maybe that will help you with pinpointing the cause of the problem.
subclipse问题
HI: I'm from China.I'm a developer for java.I find a problem about subclipse.I use window 7 system for developtment. because i often switch address for svn.sometimes i'm in outter net,but sometimes i'm in inner net.so I write something in host file. host (system32\etc).so i only change host content when i change net. for exmple, svn x,x,x,x inner net . i only change config to svn y.y.y.y but i am in outter net.i must connect internet through proxy.this time,i connect subclipse through proxy,but this isn't work. so,I hope you can help me solve this problem,perhaps this's a bug .when I set proxy for subclipse,subclipse isn't read host file. Thank you! good work! liming zhang
Wrong last changed rev after "svn cp"
Hi. I have the an issue, which I already found referenced in a mailing list posting (for example here: http://mail-archives.apache.org/mod_mbox/subversion-users/201003.mbox/%3Calpine.561.2.00.1003301058490.1236@daniel2.local%3E). However I couldn't find any related issues in the bug-tracker, or other indications whether this is an intended behaviour or a bug that will be fixed. In short the behavior can be reproduced like this: I start from a new repository and a fresh checkout wc of the repository root: --- > mkdir A; touch A/file > svn add -q A > svn ci -q -m "add A" A > svn cp ^/A ^/A2 -m "add A2" Committed revision 2. > svn up -q > svn info A A/file | grep "Last Changed Rev" Last Changed Rev: 1 Last Changed Rev: 1 > svn info A2 A2/file | grep "Last Changed Rev" Last Changed Rev: 2 Last Changed Rev: 1 --- Why do the directory "A2" and the file "A2/file" have different Last Changed Revision? For my use case this is very bad, as we are using keyword substitution for $URL$ and $Rev$ in "A2/file" to uniquely identify printouts of that file, with its electronic copy in the repository. With the above behaviour that's not possible, as "A2/file" does not exist at revision 1. I reproduced the bug with version 1.7.6 (linux server and command line client; test installation), and also with an 1.6.12 server (linux production server) combined with a 1.6.17 and 1.7.6 tortoiseSVN windows client. Cheers, Volker
Re: Wrong last changed rev after "svn cp"
On Wed, Sep 26, 2012 at 4:58 PM, Volker Daum wrote: > Hi. > > I have the an issue, which I already found referenced in a mailing list > posting (for example here: > http://mail-archives.apache.org/mod_mbox/subversion-users/201003.mbox/%3Calpine.561.2.00.1003301058490.1236@daniel2.local%3E). > However I couldn't find any related issues in the bug-tracker, or other > indications whether this is an intended behaviour or a bug that will be fixed. > In short the behavior can be reproduced like this: > > I start from a new repository and a fresh checkout wc of the repository root: > --- >> mkdir A; touch A/file >> svn add -q A >> svn ci -q -m "add A" A >> svn cp ^/A ^/A2 -m "add A2" > > Committed revision 2. >> svn up -q >> svn info A A/file | grep "Last Changed Rev" > Last Changed Rev: 1 > Last Changed Rev: 1 >> svn info A2 A2/file | grep "Last Changed Rev" > Last Changed Rev: 2 > Last Changed Rev: 1 > --- > > Why do the directory "A2" and the file "A2/file" have different Last Changed > Revision? > > For my use case this is very bad, as we are using keyword substitution for > $URL$ and $Rev$ in "A2/file" to uniquely identify printouts of that file, > with its electronic copy in the repository. With the above behaviour that's > not possible, as "A2/file" does not exist at revision 1. > > I reproduced the bug with version 1.7.6 (linux server and command line > client; test installation), and also with an 1.6.12 server (linux production > server) combined with a 1.6.17 and 1.7.6 tortoiseSVN windows client. > Hi Volker, The short answer is: this is intended behavior, and you shouldn't use the LastChangedRev as a peg revision identifier in combination with the URL. This is not a supported use case. See this recent dev-thread for some more discussion: http://thread.gmane.org/gmane.comp.version-control.subversion.devel/136663 The thread actually started with another issue related to LastChangedRev (which was identified as a real issue, which was filed here: http://subversion.tigris.org/issues/show_bug.cgi?id=4203). But during the (rather long) discussion the issue you mention actually came up. See this mail in the thread: http://thread.gmane.org/gmane.comp.version-control.subversion.devel/136663/focus=136719 where C. Michael Pilato says: "Finally, (LCR, URL) was never intended to be used a unique coordinate pair for identifying resources. That it work out as such most of the time might be a benefit, but was not a feature designed into the system." -- Johan
Re: Wrong last changed rev after "svn cp"
Hi Johan. Thanks for your reply. I was already afraid of that... Do you have any suggestion how I could solve my use case anyway (embedding a PEG revision in the file)? Text substitution in a pre-commit hook? The client knows the PEG revision of its working copy files I guess. So one could hack a keyword substitution for that into the client. How difficult would that be? Volker Original-Nachricht > Datum: Wed, 26 Sep 2012 17:31:02 +0200 > Von: Johan Corveleyn > An: Volker Daum > CC: users@subversion.apache.org > Betreff: Re: Wrong last changed rev after "svn cp" > On Wed, Sep 26, 2012 at 4:58 PM, Volker Daum wrote: > > Hi. > > > > I have the an issue, which I already found referenced in a mailing list > posting (for example here: > http://mail-archives.apache.org/mod_mbox/subversion-users/201003.mbox/%3Calpine.561.2.00.1003301058490.1236@daniel2.local%3E). > However I couldn't find any related issues in the bug-tracker, or other > indications whether this is an intended behaviour or a bug that will be > fixed. > > In short the behavior can be reproduced like this: > > > > I start from a new repository and a fresh checkout wc of the repository > root: > > --- > >> mkdir A; touch A/file > >> svn add -q A > >> svn ci -q -m "add A" A > >> svn cp ^/A ^/A2 -m "add A2" > > > > Committed revision 2. > >> svn up -q > >> svn info A A/file | grep "Last Changed Rev" > > Last Changed Rev: 1 > > Last Changed Rev: 1 > >> svn info A2 A2/file | grep "Last Changed Rev" > > Last Changed Rev: 2 > > Last Changed Rev: 1 > > --- > > > > Why do the directory "A2" and the file "A2/file" have different Last > Changed Revision? > > > > For my use case this is very bad, as we are using keyword substitution > for $URL$ and $Rev$ in "A2/file" to uniquely identify printouts of that > file, with its electronic copy in the repository. With the above behaviour > that's not possible, as "A2/file" does not exist at revision 1. > > > > I reproduced the bug with version 1.7.6 (linux server and command line > client; test installation), and also with an 1.6.12 server (linux production > server) combined with a 1.6.17 and 1.7.6 tortoiseSVN windows client. > > > > Hi Volker, > > The short answer is: this is intended behavior, and you shouldn't use > the LastChangedRev as a peg revision identifier in combination with > the URL. This is not a supported use case. > > See this recent dev-thread for some more discussion: > > > http://thread.gmane.org/gmane.comp.version-control.subversion.devel/136663 > > The thread actually started with another issue related to > LastChangedRev (which was identified as a real issue, which was filed > here: > http://subversion.tigris.org/issues/show_bug.cgi?id=4203). But during > the (rather long) discussion the issue you mention actually came up. > See this mail in the thread: > > > http://thread.gmane.org/gmane.comp.version-control.subversion.devel/136663/focus=136719 > > where C. Michael Pilato says: "Finally, (LCR, URL) was never intended > to be used a unique coordinate pair for identifying resources. That > it work out as such most of the time might be a benefit, but was not a > feature designed into the system." > > > -- > Johan
Re: Code Reverting Itself
How exactly does your production deployment work and how do you verify? It dumps the release branch of my files via SFTP onto my server. When the deployment is complete, I check to see if the files are correct, which they are. This one instance, it was correct and I checked again to see that the files are back to the way it was before, but I didn't do it though this method. I rsync'd the files to their correct destinations and everything worked, only to find that it was broken again 10 minutes later. Do you use ssh and verify after restarting you web server by using the production website? Yes, I SSH personally to verify that the changes are there. The change that I was working on, it didn't require me to restart the site as it was working just fine when I put it on my testing and staging environments. While it could be the case, Stefan, I don't think it can be possible. I use Eclipse Helios and it prompts me that there are changes and the code updates when you do a 'svn update' in it. Also, I'm using SVN 1.6 via the apt repository. But thank you for the suggestion. :) A common problem case is: > > - You have a versioned file open in an editor. > - You run 'svn update' and the file receives changes from the repository. > - The editor doesn't notice the file has been changed on disk, so the >changes brought in by the update are not reflected in the editor window. > - You save from the editor, overwriting changes brought in during the > update. > - You commit the current state without checking that what you're >committing is really what you intend to commit, undoing already >committed changes. > > I suspect you're running into some variant of this problem. > The usual workaround is to get a smarter editor, or close the editor > before running 'svn update'. > > You should review the changes which were actually committed to find out > what happened. In Subversion 1.7 you can run > svn log --diff > on a file which had changes undone accidentally. Then check each diff > for changes that are unrelated to what was supposed to be committed. > Maybe that will help you with pinpointing the cause of the problem. On Wed, Sep 26, 2012 at 2:47 AM, Thorsten Schöning wrote: > Guten Tag Kenny Raghunath, > am Dienstag, 25. September 2012 um 22:21 schrieben Sie: > > > Anyone have any suggestions on what I can do to fix this? > > It's really unlikely Subversion itself is the problem, it surely has > something to do with your deployment, working copies, merge strategies > or something like that. If I were you I would spent some time reading > the logs and especially the diffs per Commit on the reverted code, > there surely is some commit which reverts it and from your log message > you may get a hint on what exactly you did during the development of > this commit. > > As for your deployment issues, as you say you deploy manually to your > production system, you should consider increasing log level of your > deployment tool, have a look at timestamps of the reverted code etc. > How exactly does your production deployment work and how do you > verify? Do you use ssh and verify after restarting you web server by > using the production website? Especially on Linux files can be > replaced during they are used, but the programs still using them won't > see the new verisons unless they open new handles to the files etc. > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon.030-2 1001-310 > Fax...05151- 9468- 88 > Mobil..0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > > -- Kenny Raghunath Network/Systems Administrator http://frameweld.com
Re: Wrong last changed rev after "svn cp"
[ Please do not top-post on this list, try to put your reply inline or at the bottom. More below. On Wed, Sep 26, 2012 at 6:34 PM, Volker Daum wrote: > Original-Nachricht >> Datum: Wed, 26 Sep 2012 17:31:02 +0200 >> Von: Johan Corveleyn >> An: Volker Daum >> CC: users@subversion.apache.org >> Betreff: Re: Wrong last changed rev after "svn cp" > >> On Wed, Sep 26, 2012 at 4:58 PM, Volker Daum wrote: >> > Hi. >> > >> > I have the an issue, which I already found referenced in a mailing list >> posting (for example here: >> http://mail-archives.apache.org/mod_mbox/subversion-users/201003.mbox/%3Calpine.561.2.00.1003301058490.1236@daniel2.local%3E). >> However I couldn't find any related issues in the bug-tracker, or other >> indications whether this is an intended behaviour or a bug that will be >> fixed. >> > In short the behavior can be reproduced like this: >> > >> > I start from a new repository and a fresh checkout wc of the repository >> root: >> > --- >> >> mkdir A; touch A/file >> >> svn add -q A >> >> svn ci -q -m "add A" A >> >> svn cp ^/A ^/A2 -m "add A2" >> > >> > Committed revision 2. >> >> svn up -q >> >> svn info A A/file | grep "Last Changed Rev" >> > Last Changed Rev: 1 >> > Last Changed Rev: 1 >> >> svn info A2 A2/file | grep "Last Changed Rev" >> > Last Changed Rev: 2 >> > Last Changed Rev: 1 >> > --- >> > >> > Why do the directory "A2" and the file "A2/file" have different Last >> Changed Revision? >> > >> > For my use case this is very bad, as we are using keyword substitution >> for $URL$ and $Rev$ in "A2/file" to uniquely identify printouts of that >> file, with its electronic copy in the repository. With the above behaviour >> that's not possible, as "A2/file" does not exist at revision 1. >> > >> > I reproduced the bug with version 1.7.6 (linux server and command line >> client; test installation), and also with an 1.6.12 server (linux production >> server) combined with a 1.6.17 and 1.7.6 tortoiseSVN windows client. >> > >> >> Hi Volker, >> >> The short answer is: this is intended behavior, and you shouldn't use >> the LastChangedRev as a peg revision identifier in combination with >> the URL. This is not a supported use case. >> >> See this recent dev-thread for some more discussion: >> >> >> http://thread.gmane.org/gmane.comp.version-control.subversion.devel/136663 >> >> The thread actually started with another issue related to >> LastChangedRev (which was identified as a real issue, which was filed >> here: >> http://subversion.tigris.org/issues/show_bug.cgi?id=4203). But during >> the (rather long) discussion the issue you mention actually came up. >> See this mail in the thread: >> >> >> http://thread.gmane.org/gmane.comp.version-control.subversion.devel/136663/focus=136719 >> >> where C. Michael Pilato says: "Finally, (LCR, URL) was never intended >> to be used a unique coordinate pair for identifying resources. That >> it work out as such most of the time might be a benefit, but was not a >> feature designed into the system." >> > Hi Johan. > > Thanks for your reply. I was already afraid of that... > Do you have any suggestion how I could solve my use case anyway (embedding a > PEG revision in the file)? > > Text substitution in a pre-commit hook? > The client knows the PEG revision of its working copy files I guess. So one > could hack a keyword substitution for that into the client. How difficult > would that be? > Hm, I don't know a good solution for that. But what you certainly shouldn't do is manipulate the file in the pre-commit hook. That's a recipe for problems, because after the commit the repository and the working copy from which you committed will have a different idea about what was committed. This makes the originating working copy corrupt. I'm not sure if hacking your own keyword substitution is doable. There is an open issue about custom keywords [1], but from the mere amount of discussion and patches therein (and the age of the issue, 10 years old) it doesn't seem like an easy problem. If you want to contribute though, help is always welcome (in this case, I believe you'd have to start with a design discussion on the dev-list). Maybe someone else on this list has a good idea? The only thing I can think of is pre-processing your files before commit (make a wrapper around "svn commit" which does some automatic change in the file before commit (but be careful not to mess things up)) or some kind of post-processing after you export/checkout, before printing the file (maybe as part of some build script or something similar). [1] http://subversion.tigris.org/issues/show_bug.cgi?id=890 (Implementation of Custom keywords) -- Johan
Re: Code Reverting Itself
On Wed, Sep 26, 2012 at 2:38 PM, Kenny Raghunath wrote: > > While it could be the case, Stefan, I don't think it can be possible. I use > Eclipse Helios and it prompts me that there are changes and the code updates > when you do a 'svn update' in it. Also, I'm using SVN 1.6 via the apt > repository. But thank you for the suggestion. :) Can you do diffs against the revisions to be sure the change was actually committed when you thought it was and then subsequently reverted? A possible cause of not committing would be some recursive action in the directory that also changes the pristine copy or bumps its timestamp. -- Les Mikesell lesmikes...@gmail.com
