Skip to content

Loading…

Problem with Headers folder when using SVN #247

Closed
vytis opened this Issue · 16 comments

8 participants

@vytis

My project uses SVN and I have added Pods directory to the repository. The problem is that every time i run pod install I suspect that Headers folder is recreated and SVN stops tracking changes in that folder. This probably happens because all .svn directories have disappeared from it.

When looking at svn status I can see that Headers folder is marked with ~ sign (more info). This is very annoying, because the only way to fix this is to commit the deletion of Headers and then commit again with the updated version

@alloy
CocoaPods member

Ah yes, SVN and directories… :)

I don’t really want to add complexity to check if any of the subdirs is or isn't needed anymore, just wiping out the complete dir and creating what is needed is much easier.

In a future version it shouldn’t be necessary to include the Pods directory in your SCM at all, but until then I’m wondering if there are any simple workarounds we could use. Any idea?

@astralbodies

Is it possible to have the Header folder regenerated on each machine that has the project checked out? I could exclude that folder from Subversion completely if I can manually recreate the headers.

@fabiopelosin
CocoaPods member

@astralbodies pod install doesn't touch the installed pods and it regenerates the support files on every run. Therefore, your suggestion should work. Can you confirm this workaround?

@astralbodies

@irrationalfab I can confirm ignoring the entire Headers directory from SVN works. Devs will have to remember to run pod install after initial checkout or when pulling an update with dependency changes. Small annoyance but worth it.

@fabiopelosin
CocoaPods member

@astralbodies Thanks for checking.

I think that this workaround is a reasonable solution until there will be the need keep the pods folder under SCM.

@Zyphrax

Another workaround is to use subversion 1.7:

Subversion 1.7 only places a .svn folder in the root of your working folder (not every subfolder). When Cocoapods removes the Header folder they won't get status obstructed and you can simply add the new folders/files and commit.

XCode at this moment isn't subversion 1.7 compatible yet. You can make it compatible with 1.7 by doing a few simple steps (you have to do these every time you update XCode). For more info look at his url: http://tgoode.com/2012/03/31/use-svn-1-7-in-xcode-4-3/. You can install subversion 1.7 in a matter of minutes using brew.

I think I update pods more frequently than XCode so this seems like a good trade-off.

@cellularmitosis

I just got bitten by this, as I just switched from excluding ./Pods in svn to including it as part of the svn checkin, so every time I run 'pod install', I run into the Headers and BuildHeaders svn issue.

For me, I'm looking for a solution other than just having all of the devs run 'pod install', because I'm trying to stay in a situation where having CocoaPods installed is optional. I.e., I want another dev to take a look at something without having to have CocoaPods installed, etc.

But beggars can't be choosers :)

@alloy
CocoaPods member

@cellularmitosis I see your dilemma… Might it be an idea for you to use git-svn when you run pod install? That should fix the issue. I think :)

@cellularmitosis

For now, I'm fleshing out the use-case of keeping most of Pods/ in svn, but still requiring each dev to run 'pod install' upon checkout.

Initially I tried just pulling each Pods/Foo subdir into svn, and leaving out all of the Pods.xcodeproj, Pods.xcconfig, etc files which are generated by pod.

Unfortunately, I discovered that if Pods.xcodeproj doesn't exist, pod will ignore all of the Pods/Foo dirs and overwrite them with a fresh pod pull from upstream. This of course results in a directory full of missing .svn directories, which makes baby jesus cry.

So, I've switched to pulling Pods.xcodeproj into svn for now. However, the issue I've found there is that Pods.xcodeproj gets modified everytime you run 'pod install', whether or not any pods actually got updated. This results in an svn workflow which is a bit more noisy than it needs to be, but this appears to be a working solution for now.

Just though I'd add my experience to this thread for others who are about to journey the same path.

(hadn't heard of git-svn, I'll take a look at it. thanks!)

@cellularmitosis

Also, when I migrated to having Pods/ in svn, I ran into an problem during the copy-resources script, where .bundle files would fail to copy because of read-only permissions of a .svn directory buried inside of the bundle.

I came up with a work-around which looks for .svn, and if it finds it, performs an 'svn export' instead of a 'cp':

https://gist.github.com/3764541

I'm not sure this is the most elegant solution, but it appears to work.

@fabiopelosin
CocoaPods member

Regarding the headers folder, with the current changes in the resolver now is not that difficult to just update the header folders.


@cellularmitosis:

I discovered that if Pods.xcodeproj doesn't exist, pod will ignore all of the Pods/Foo dirs and overwrite them with a fresh pod pull from upstream

This is not the intended behavior. This should not happen if the Podfile.lock doesn't exists and should be unrelated to the Pods project (since v0.14.0). Can you confirm that there is a bug?

Also, when I migrated to having Pods/ in svn, I ran into an problem during the copy-resources script, where .bundle files would fail to copy because of read-only permissions of a .svn directory buried inside of the bundle.

See #545

@fabiopelosin fabiopelosin was assigned
@cellularmitosis

I'll have to double-check this. At one point I noticed it seemed to re-do everything in Pods if Podfile.lock was missing.

@fabiopelosin
CocoaPods member

This is the intended behavior. Although it is not fully implemented:

  • The Podfile indicates what the user wants.
  • The Podfile.lock indicates (with information from the Podfile) what exact version should be installed, it is also used to compute what changed in the Podfile did change (changes in :head, :local, and external dependencies options).
  • The Pods/Manifest.lock is used to compute what it is installed in a Pods folder. Diffing the pods that should be installed with the information of this file, tells what pods actually do need to be installed. This is a separate file because the Pods folder often is not under source control, however, currently it is not implemented and we are using Podfile.lock. Finally, if no manifest is found we assume that we need to install everything because we can't know reliably what is installed.
@deepumukundan

Is this issue resolved in the latest Cocoapods? I was happily keying in and integrating 3rd party code in a project of mine for my company when I discovered the magical Cocoapods. But my company uses SVN, and I ran into this issue and now my version control system does not like my dependency manager.

Screen Shot 2013-02-19 at 11 36 38 AM

How can I fix this other than updating SVN? I have a few obstructing messages which says some folders are blocking item under version control. I think with some effort I should be able to restart the whole versioning, leaving my old history for good, but if this issue will happen again I might need a futureproof way of fixing this.

@alloy
CocoaPods member

@deepumukundan Alas not. The only two solutions atm are to update SVN or use git-svn.

@CocoaPodsBot CocoaPodsBot was assigned by vytis
@CocoaPodsBot

@frosty closed with reason "Mavericks now comes with SVN 1.7 out of the box, which means that this won't be an issue if you're using the system-provided SVN."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.