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 <tschoening_at_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_at_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
Received on 2012-09-26 21:41:11 CEST