You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Kenny Raghunath <Ke...@frameweld.com> on 2012/09/25 22:21:48 UTC

Code Reverting Itself

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!

Re: Code Reverting Itself

Posted by Les Mikesell <le...@gmail.com>.
On Wed, Sep 26, 2012 at 2:38 PM, Kenny Raghunath
<sk...@gmail.com> 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
     lesmikesell@gmail.com

Re: Code Reverting Itself

Posted by Kenny Raghunath <sk...@gmail.com>.
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 <ts...@am-soft.de>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.Schoening@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: Code Reverting Itself

Posted by Thorsten Schöning <ts...@am-soft.de>.
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.Schoening@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


Re: Code Reverting Itself

Posted by Nico Kadel-Garcia <nk...@gmail.com>.
[ sorry about bad post! ]

Nico Kadel-Garcia
Email: nico.kadel@tufts.edu
Sent from iPhone

On Sep 26, 2012, at 5:59, Stefan Sperling <st...@elego.de> wrote:
> 
> A common problem case is:
> 
> - You have a versioned file open in an editor.

Oh, yes, that one is fun. It's also aggravated by deployment processes that edit files in place, rather than Subversion managing a template and deploying a source control excluded file, built at deployment time from local settings.

> - 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'.

There are good hooks in Emacs, for example, with psvn.el installed. But that now required Emacs-23 or later.

There is also a commonly used procedure of doing "svn checkout" on top of an existing working copy without clearing away old local changes with "svn revert". I ran into that one, with the "Tuttle" configuration management system. The results led to various merging adventures for people who didn't realize old test config settings were not cleared nightly, and wound up committing them back upstream.

> 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

Posted by Nico Kadel-Garcia <nk...@gmail.com>.

Nico Kadel-Garcia
Email: nico.kadel@tufts.edu
Sent from iPhone

On Sep 26, 2012, at 5:59, Stefan Sperling <st...@elego.de> 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.

Re: Code Reverting Itself

Posted by Stefan Sperling <st...@elego.de>.
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.