I''m scratching my head over how to make subversion do what I want. During development I track the SVN HEAD release of Rails linked-in as an external in the vendor directory. For the Rails-related files in the public directory I use symlinks to the original files. For development this works, but not for tagging and building a release gem. The problems I''m currently having are these - When tagging the current version by svn copy-ing it to .../tags/release-0.x.0, the release of the svn:external for Rails still points to SVN HEAD, not to the revision current at the time of tagging. I don''t see how to fix the Rails revision without error-prone manual intervention. - The relative symlinks break when rake gempackage copies files to its working version that it uses for packaging. I think that symlinks to external files, i.e. ones not included in the package, should be substituted by the original files. That would require changes to gem, though. Is it possible to get the same result without them? Michael -- Michael Schuerig They tell you that the darkness mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org Is a blessing in disguise http://www.schuerig.de/michael/ --Janis Ian, From Me To You
On 7/12/05, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote:> > I''m scratching my head over how to make subversion do what I want. > During development I track the SVN HEAD release of Rails linked-in as > an external in the vendor directory. For the Rails-related files in the > public directory I use symlinks to the original files. > > For development this works, but not for tagging and building a release > gem. The problems I''m currently having are these > > - When tagging the current version by svn copy-ing it > to .../tags/release-0.x.0, the release of the svn:external for Rails > still points to SVN HEAD, not to the revision current at the time of > tagging. I don''t see how to fix the Rails revision without error-prone > manual intervention. > > - The relative symlinks break when rake gempackage copies files to its > working version that it uses for packaging. I think that symlinks to > external files, i.e. ones not included in the package, should be > substituted by the original files. That would require changes to gem, > though. Is it possible to get the same result without them?I''d like to see an answer to this too! I can''t figure it out either. Also, why do you use gems to package a rails site? What''s the benefit?
Michael Schuerig
2005-Jul-13 08:52 UTC
Re: Subversion, gem packaging, externals, and symlinks
On Wednesday 13 July 2005 08:00, Joe Van Dyk wrote:> Also, why do you use gems to package a rails site? What''s the > benefit?I''m trying to package two things. (1) BoilerPlate[*], my "app skeleton" (to avoid the f-word) on top of Rails. This should become a gem. (2) A demo app for BoilerPlate as zip and tar.gz In my development setup, I have the demo app at the root and the generic code in vendor/boilerplate. Rails SVN HEAD is linked-in via svn:externals at vendor/rails. The demo app has several symlinks to JavaScript and stylesheet files and images contained in Rails and BoilerPlate. This is all very convenient for development, but not for tagging a release and packaging. Also, when deployed, things should be different. BoilerPlate itself should be installed as a gem, the demo app can be unpacked anywhere and has an empty vendor directory. Michael [*] http://www.schuerig.de/michael/boilerplate/ -- Michael Schuerig The more it stays the same, mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org The less it changes! http://www.schuerig.de/michael/ --Spinal Tap, The Majesty of Rock