Use svn switch instead of svn update for cached_copy #40

Closed
iGEL opened this Issue May 24, 2011 · 22 comments

Comments

Projects
None yet
6 participants
@iGEL
Contributor

iGEL commented May 24, 2011

If using the cached_copy, capistrano issues a svn update command, if a cached copy is available. But if you switch the branch or tag, that command won't do anything useful. If you use svn switch, it'll switch to the new repo location (if necessary) AND update to the given revision. So there is no downside in using svn switch instead svn update.

@leehambley

This comment has been minimized.

Show comment Hide comment
@leehambley

leehambley May 24, 2011

Owner

So there is no downside in using svn switch instead svn update.

Sounds great, I'll take a patch and tests – Nobody that I know personally is using SVN to test this, and most of the focus is on Git… but I'll happily merge something if you have a few minutes to write it.

Owner

leehambley commented May 24, 2011

So there is no downside in using svn switch instead svn update.

Sounds great, I'll take a patch and tests – Nobody that I know personally is using SVN to test this, and most of the focus is on Git… but I'll happily merge something if you have a few minutes to write it.

@leehambley

This comment has been minimized.

Show comment Hide comment
@leehambley

leehambley Jun 16, 2011

Owner

@iGEL bump, and plans to submit this patch?

Owner

leehambley commented Jun 16, 2011

@iGEL bump, and plans to submit this patch?

@leehambley

This comment has been minimized.

Show comment Hide comment
@leehambley

leehambley Jun 25, 2011

Owner

Author never came back with enhancements. (Please, do if you can write tests, and test a pre-release.)

Owner

leehambley commented Jun 25, 2011

Author never came back with enhancements. (Please, do if you can write tests, and test a pre-release.)

@leehambley leehambley closed this Jun 25, 2011

@iGEL

This comment has been minimized.

Show comment Hide comment
@iGEL

iGEL Jul 23, 2011

Contributor

I finally wrote the test & patch. https://gist.github.com/1101225 Hope it's fine that way.

Contributor

iGEL commented Jul 23, 2011

I finally wrote the test & patch. https://gist.github.com/1101225 Hope it's fine that way.

@leehambley leehambley reopened this Aug 31, 2011

@leehambley

This comment has been minimized.

Show comment Hide comment
@leehambley

leehambley Aug 31, 2011

Owner

Thanks, sorry I missed the patch @iGEL will take a proper look shortly.

Owner

leehambley commented Aug 31, 2011

Thanks, sorry I missed the patch @iGEL will take a proper look shortly.

@richmeyers

This comment has been minimized.

Show comment Hide comment
@richmeyers

richmeyers Sep 13, 2011

I just had to deal with this again as I forgot to copy the patch from one project to another before this bug remanifested itself.

What makes this bug a bug is the silent failure to deploy the code specified. If capistrano told me that the cached copy was for the wrong branch, I would have known to delete the cached copy or otherwise fix the problem. As it is the deployment appears to work fine, then later someone notices that the application does not work as expected, and eventually after spending quite some time figuring out why the behavior of the code does not match the behavior of what was (requested to be) deployed, the root cause is discovered. With much frustration I might add.

This is the overlay patch we have been using for over a year: https://gist.github.com/1215416

Require it in your capfile/deploy.rb and specify minimum svn version in deploy.rb.

Note that specifying revision while switching branches is supported by svn 1.5+ only. Before 1.5 you can't do this. The trick with pre-1.5 is the current path being deployed may not exist in the revision which was checked out on the remote end, so properly handling switching and updating is tricky. I think on pre-1.5 versions capistrano should abort if the cached copy's branch is different from the branch being deployed, at which point the user would have to manually kill the cached copy.

Rhel/centos 5 ship subversion 1.4 last time I checked.

I'm pretty sure I wrote all of this in https://capistrano.lighthouseapp.com/projects/8716-capistrano/tickets/46 which no longer seems to exist.

I just had to deal with this again as I forgot to copy the patch from one project to another before this bug remanifested itself.

What makes this bug a bug is the silent failure to deploy the code specified. If capistrano told me that the cached copy was for the wrong branch, I would have known to delete the cached copy or otherwise fix the problem. As it is the deployment appears to work fine, then later someone notices that the application does not work as expected, and eventually after spending quite some time figuring out why the behavior of the code does not match the behavior of what was (requested to be) deployed, the root cause is discovered. With much frustration I might add.

This is the overlay patch we have been using for over a year: https://gist.github.com/1215416

Require it in your capfile/deploy.rb and specify minimum svn version in deploy.rb.

Note that specifying revision while switching branches is supported by svn 1.5+ only. Before 1.5 you can't do this. The trick with pre-1.5 is the current path being deployed may not exist in the revision which was checked out on the remote end, so properly handling switching and updating is tricky. I think on pre-1.5 versions capistrano should abort if the cached copy's branch is different from the branch being deployed, at which point the user would have to manually kill the cached copy.

Rhel/centos 5 ship subversion 1.4 last time I checked.

I'm pretty sure I wrote all of this in https://capistrano.lighthouseapp.com/projects/8716-capistrano/tickets/46 which no longer seems to exist.

@leehambley

This comment has been minimized.

Show comment Hide comment
@leehambley

leehambley Sep 14, 2011

Owner

I'm pretty sure I wrote all of this in [https://capistrano.lighthouseapp.com/projects/8716-capistrano/tickets/46] which no longer seems to exist.

Lighthouse was deprecated from the beginning of the year, there was a mailing list announcement, and I invited all ticket authors there to move their issues to Github.

I'll deal with your issue at some point in the next 1/2 days.

Owner

leehambley commented Sep 14, 2011

I'm pretty sure I wrote all of this in [https://capistrano.lighthouseapp.com/projects/8716-capistrano/tickets/46] which no longer seems to exist.

Lighthouse was deprecated from the beginning of the year, there was a mailing list announcement, and I invited all ticket authors there to move their issues to Github.

I'll deal with your issue at some point in the next 1/2 days.

@richmeyers

This comment has been minimized.

Show comment Hide comment
@richmeyers

richmeyers Sep 21, 2011

I enhanced https://gist.github.com/1215416 with a remote svn version check and additional logic to fail deployment if branch switching is attempted on svn before 1.5.

Lighthouse was deprecated

"Deprecated" means the thing continues to exist - http://en.wikipedia.org/wiki/Deprecation. The old bug tracker was completely removed it looks like. This I don't understand at all. Why would you destroy the work of everyone who submitted bugs and patches?

I enhanced https://gist.github.com/1215416 with a remote svn version check and additional logic to fail deployment if branch switching is attempted on svn before 1.5.

Lighthouse was deprecated

"Deprecated" means the thing continues to exist - http://en.wikipedia.org/wiki/Deprecation. The old bug tracker was completely removed it looks like. This I don't understand at all. Why would you destroy the work of everyone who submitted bugs and patches?

@leehambley

This comment has been minimized.

Show comment Hide comment
@leehambley

leehambley Sep 22, 2011

Owner

@richmeyers thanks for the patch, I'd already applied the code from @iGEL, pending for release later today.

"Deprecated" means the thing continues to exist - http://en.wikipedia.org/wiki/Deprecation. The old bug tracker was completely removed it looks like. This I don't understand at all.

It was deprecated for a number of months before being finally removed, I was getting split issues between here and Lighthouse.

Why would you destroy the work of everyone who submitted bugs and patches?

At some point I had to force the issue, Lighthouse wouldn't let me lock/archive the account as I wasn't the owner, and I was still receiving bug reports there, which were going unanswered because I wasn't ever referring to Lighthouse. In the end Jamis and I agreed that enough time had passed, and the issues had gone cold enough to let Lighthouse really disappear. If you think my judgement was off, I apologise.

I would prefer not to be drawn into a public discussion about my methods, but I encourage you to contact me if you wish to discuss it further, I believe almost all of us could benefit from some peer advice from time to time.

Finally, thank you for the patch, OpenSource is rarely smooth sailing, we're all human, I'll get it released in the next few hours, unfortunately one of the other pull requests doesn't apply cleanly, and it's making some problems.

Owner

leehambley commented Sep 22, 2011

@richmeyers thanks for the patch, I'd already applied the code from @iGEL, pending for release later today.

"Deprecated" means the thing continues to exist - http://en.wikipedia.org/wiki/Deprecation. The old bug tracker was completely removed it looks like. This I don't understand at all.

It was deprecated for a number of months before being finally removed, I was getting split issues between here and Lighthouse.

Why would you destroy the work of everyone who submitted bugs and patches?

At some point I had to force the issue, Lighthouse wouldn't let me lock/archive the account as I wasn't the owner, and I was still receiving bug reports there, which were going unanswered because I wasn't ever referring to Lighthouse. In the end Jamis and I agreed that enough time had passed, and the issues had gone cold enough to let Lighthouse really disappear. If you think my judgement was off, I apologise.

I would prefer not to be drawn into a public discussion about my methods, but I encourage you to contact me if you wish to discuss it further, I believe almost all of us could benefit from some peer advice from time to time.

Finally, thank you for the patch, OpenSource is rarely smooth sailing, we're all human, I'll get it released in the next few hours, unfortunately one of the other pull requests doesn't apply cleanly, and it's making some problems.

@richmeyers

This comment has been minimized.

Show comment Hide comment
@richmeyers

richmeyers Sep 22, 2011

I tried the logic in the patch by @iGEL on a test repository with subversion 1.4 and 1.6 and it seems to do the right thing, thus rendering contortions in my patch unnecessary. I'm looking forward to an official release incorporating the fix.

I tried the logic in the patch by @iGEL on a test repository with subversion 1.4 and 1.6 and it seems to do the right thing, thus rendering contortions in my patch unnecessary. I'm looking forward to an official release incorporating the fix.

@boutell

This comment has been minimized.

Show comment Hide comment
@boutell

boutell Nov 30, 2011

This fix breaks deployment of projects that use svn externals. svn switch with a revision number concerns itself only with the main project and does not implicitly 'svn update' any svn externals. Our projects rely heavily on svn externals, so this fix broke them thoroughly.

Is there a maintainable way to roll this back or add an explicit 'svn update' to the process following the svn switch command in my local project?

boutell commented Nov 30, 2011

This fix breaks deployment of projects that use svn externals. svn switch with a revision number concerns itself only with the main project and does not implicitly 'svn update' any svn externals. Our projects rely heavily on svn externals, so this fix broke them thoroughly.

Is there a maintainable way to roll this back or add an explicit 'svn update' to the process following the svn switch command in my local project?

@leehambley

This comment has been minimized.

Show comment Hide comment
@leehambley

leehambley Nov 30, 2011

Owner

@boutell - do you know if there's a way to make svnswitch work for projects
using externals. (also word to the wise, lock Capistrano in your Gemfile,
when your production server is at the hands of a Gem, you'd better test
well before upgrading Cap, it's a mistake that many people make)

Owner

leehambley commented Nov 30, 2011

@boutell - do you know if there's a way to make svnswitch work for projects
using externals. (also word to the wise, lock Capistrano in your Gemfile,
when your production server is at the hands of a Gem, you'd better test
well before upgrading Cap, it's a mistake that many people make)

@boutell

This comment has been minimized.

Show comment Hide comment
@boutell

boutell Nov 30, 2011

Update: I patched the gem on my local copy to do the update command that was removed - after the switch command that was added, so that we also get the benefits this change was originally intended to achieve.

Yes, this updates the main project twice, but I see no simple way to avoid that and not break updates of projects that use svn:externals.

Hopefully this change can be made upstream so that we can stay current without re-breaking our deploys (:

boutell commented Nov 30, 2011

Update: I patched the gem on my local copy to do the update command that was removed - after the switch command that was added, so that we also get the benefits this change was originally intended to achieve.

Yes, this updates the main project twice, but I see no simple way to avoid that and not break updates of projects that use svn:externals.

Hopefully this change can be made upstream so that we can stay current without re-breaking our deploys (:

@boutell

This comment has been minimized.

Show comment Hide comment
@boutell

boutell Nov 30, 2011

leehambley: thanks for the advice. How would I lock Capistrano? I'm googling but seem to be looking for the wrong things. As you might guess I'm not really a Ruby guy. Not yet anyway.

svn switch does not appear to have any love for externals at all. Which makes sense because externals are really separate checkouts anyway.

But on reflection there is no real penalty for fixing it as I suggest. Since the main project is already at the desired revision after the switch command, determing that will take almost no time, and then it'll move on to updating the externals.

boutell commented Nov 30, 2011

leehambley: thanks for the advice. How would I lock Capistrano? I'm googling but seem to be looking for the wrong things. As you might guess I'm not really a Ruby guy. Not yet anyway.

svn switch does not appear to have any love for externals at all. Which makes sense because externals are really separate checkouts anyway.

But on reflection there is no real penalty for fixing it as I suggest. Since the main project is already at the desired revision after the switch command, determing that will take almost no time, and then it'll move on to updating the externals.

@boutell

This comment has been minimized.

Show comment Hide comment
@boutell

boutell Dec 11, 2011

Bump - any hope of this simple and correct fix to a pretty serious regression for those of us who use externals? (The fix is to do both - do your svn switch command and then the svn update. The latter will add very little overhead for those not using externals because it will just determine it is on the correct revision, and it's correct for everyone.)

boutell commented Dec 11, 2011

Bump - any hope of this simple and correct fix to a pretty serious regression for those of us who use externals? (The fix is to do both - do your svn switch command and then the svn update. The latter will add very little overhead for those not using externals because it will just determine it is on the correct revision, and it's correct for everyone.)

@leehambley

This comment has been minimized.

Show comment Hide comment
@leehambley

leehambley Dec 12, 2011

Owner

Ok, I was waiting for the time to get into the SVN docs… You can expect
this to be pulled today, and pushed as a prerelease if what you say is
accurate I don't see anything standing in the way.

Owner

leehambley commented Dec 12, 2011

Ok, I was waiting for the time to get into the SVN docs… You can expect
this to be pulled today, and pushed as a prerelease if what you say is
accurate I don't see anything standing in the way.

@boutell

This comment has been minimized.

Show comment Hide comment
@boutell

boutell Dec 12, 2011

Thanks, I really appreciate it!

boutell commented Dec 12, 2011

Thanks, I really appreciate it!

@leehambley

This comment has been minimized.

Show comment Hide comment
@leehambley

leehambley Dec 12, 2011

Owner

Pre-release gem pushed 2.10.0.pre. Please be aware that the feature version is bumped because also deploy:symlink is renamed for Rake 0.9.x compatibility, is has now become deploy:create_symlink.

I literally havent tried this version, but the tests look good - please feedback any problems you run into.

Owner

leehambley commented Dec 12, 2011

Pre-release gem pushed 2.10.0.pre. Please be aware that the feature version is bumped because also deploy:symlink is renamed for Rake 0.9.x compatibility, is has now become deploy:create_symlink.

I literally havent tried this version, but the tests look good - please feedback any problems you run into.

@leehambley leehambley closed this Dec 12, 2011

@jamesprior

This comment has been minimized.

Show comment Hide comment
@jamesprior

jamesprior May 15, 2012

Is the fix for svn:externals in the 2.12.0 release?

Is the fix for svn:externals in the 2.12.0 release?

mattbrictson pushed a commit to mattbrictson/capistrano that referenced this issue Aug 24, 2016

Merge pull request #40 from nathanvda/patch-1
Capistrano v3 _is_ on rubygems.org
@NoICE

This comment has been minimized.

Show comment Hide comment
@NoICE

NoICE Dec 6, 2017

I see that in 2.12.0, 2.14.2 this issue still exists. Is that correct? All those use just svn switch bot not svn update, resulting in a small headache trying to figure out what was bundler talking about, when it said that my gemspecs changed :)

NoICE commented Dec 6, 2017

I see that in 2.12.0, 2.14.2 this issue still exists. Is that correct? All those use just svn switch bot not svn update, resulting in a small headache trying to figure out what was bundler talking about, when it said that my gemspecs changed :)

@leehambley

This comment has been minimized.

Show comment Hide comment
@leehambley

leehambley Dec 6, 2017

Owner

I'd just like to draw your attention to our announcement on 23-10-2017 -

As of this release, version 2.x of Capistrano is officially End of Life. No further releases of 2.x series are planned, and pull requests against 2.x are no longer accepted. The maintainers encourage you to upgrade to 3.x if possible.

This issue you're commenting on is nearly 7 years old! We'd be glad to help you upgrade to a none-EOL version of Capistrano, catch us on the mailing list, and/or our guides/etc!

Owner

leehambley commented Dec 6, 2017

I'd just like to draw your attention to our announcement on 23-10-2017 -

As of this release, version 2.x of Capistrano is officially End of Life. No further releases of 2.x series are planned, and pull requests against 2.x are no longer accepted. The maintainers encourage you to upgrade to 3.x if possible.

This issue you're commenting on is nearly 7 years old! We'd be glad to help you upgrade to a none-EOL version of Capistrano, catch us on the mailing list, and/or our guides/etc!

@NoICE

This comment has been minimized.

Show comment Hide comment
@NoICE

NoICE Dec 6, 2017

@leehambley thank you for your quick reply, I just wanted to know / to let others know if this is indeed fixed in versions mentioned here :-)

I just have some old projects (tons of them) which each use some old version of Capistrano and these legacy projects are not actively maintained anymore and I had to just redeploy two of them. I moved some of these projects to git, which solved this issue. I use Capistrano 3 in newer projects, but don't have resources to migrate all those projects to newer one. That's my fault though...

NoICE commented Dec 6, 2017

@leehambley thank you for your quick reply, I just wanted to know / to let others know if this is indeed fixed in versions mentioned here :-)

I just have some old projects (tons of them) which each use some old version of Capistrano and these legacy projects are not actively maintained anymore and I had to just redeploy two of them. I moved some of these projects to git, which solved this issue. I use Capistrano 3 in newer projects, but don't have resources to migrate all those projects to newer one. That's my fault though...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment