This is a little off topic, but I thought I''d post here to see what others are doing with their Rails projects. There may or may not be an easy way to do this, but I''m not a subversion expert so I''m hoping someone else can shed some light on a good way to do this for me. I''m trying to make changes (pertinent to me only) to some Rails code maintained in publicly available repositories (read only for me). For some of my projects, I set an external property on a directory within my application directory which points to some publicly shared project for which I do not need to make any changes (but want the head of the repo). I then check my top level directory into my own repository, and I can use SwitchTower to easily deploy my app. However, I''d like to do the same for some applications (for example, Typo), for which the modified files reside within the directory structure of the publicly shared app (e.g., config/database.yaml). It seems that the only way to do this is to actually copy the whole public repository into mine, and check that into my repository, making changes from there. Then whenever there are changes to the public project''s repository, I need to merge the patch into my working copy. I suppose the pain is that I need to keep a copy of the public repo around from when I first imported it to use to generate the later patches. Is this the best way to go about this? Thanks, Joe
* Joseph Hosteny (jhosteny-ee4meeAH724@public.gmane.org) [050929 11:15]:> It seems that the only way to do this is to actually copy the whole > public repository into mine, and check that into my repository, > making changes from there. Then whenever there are changes to the > public project''s repository, I need to merge the patch into my > working copy.Could you, instead, version control only your local changes for things like Typo, write a little Ruby script to merge your changes onto the Typo default and make that part of your SwitchTower deployment process? So it would do a pull of your app, including the remote resources like Typo, then the script runs to update the configs which need changing, and then the software is deployed. Rick -- http://www.rickbradley.com MUPRN: 825 | stale. things float in random email haiku | gravitationless space, [22;24r | [24;1H w [1;24r [24;2Hell-lit.
Hello Joseph, Joseph Hosteny said the following on 2005-09-29 12:12:> It seems that the only way to do this is to actually copy the whole > public repository into mine, and check that into my repository, making > changes from there. Then whenever there are changes to the public > project''s repository, I need to merge the patch into my working copy. > > I suppose the pain is that I need to keep a copy of the public repo > around from when I first imported it to use to generate the later > patches. Is this the best way to go about this?Do you know about SVK[1] ? It manages the merging part of vendor code all by itself - less headache for you. Bye ! François [1] http://svk.elixus.org/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 29, 2005, at 11:14 AM, François Beausoleil wrote:> Joseph Hosteny said the following on 2005-09-29 12:12: >> It seems that the only way to do this is to actually copy the >> whole public repository into mine, and check that into my >> repository, making changes from there. Then whenever there are >> changes to the public project''s repository, I need to merge the >> patch into my working copy. >> I suppose the pain is that I need to keep a copy of the public >> repo around from when I first imported it to use to generate the >> later patches. Is this the best way to go about this? > > Do you know about SVK[1] ? It manages the merging part of vendor > code all by itself - less headache for you.Agreed. Managing vendor branches is a dream with svk! (And so much more.) http://svk.elixus.org ;-) jeremy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDPDTWAQHALep9HFYRApdYAJ99zZdy2urE8ANms2yjkOWJJRtnCACbBvEX NzNL01wAl2S6DwA1ck32o50=tnlq -----END PGP SIGNATURE-----
On Thursday 29 September 2005 20:39, Jeremy Kemper wrote:> On Sep 29, 2005, at 11:14 AM, François Beausoleil wrote: > > Joseph Hosteny said the following on 2005-09-29 12:12: > >> It seems that the only way to do this is to actually copy the > >> whole public repository into mine, and check that into my > >> repository, making changes from there. Then whenever there are > >> changes to the public project''s repository, I need to merge the > >> patch into my working copy. > >> I suppose the pain is that I need to keep a copy of the public > >> repo around from when I first imported it to use to generate the > >> later patches. Is this the best way to go about this? > > > > Do you know about SVK[1] ? It manages the merging part of vendor > > code all by itself - less headache for you. > > Agreed. Managing vendor branches is a dream with svk! (And so much > more.) > > http://svk.elixus.orgI''ve got the same response, on the subversion mailing list no less, when I asked about the same problem. I have applied more patches to my local rails installation than I''d like to and I have found no way to keep the changes under version control. -- But I really don''t want to learn yet another VCS, I''ve only recently switched from CVS to subversion. Michael -- Michael Schuerig There is no matrix, mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org only reality. http://www.schuerig.de/michael/ --Lawrence Fishburn
Michael Schuerig said the following on 2005-09-29 15:57:> I''ve got the same response, on the subversion mailing list no less, when > I asked about the same problem. I have applied more patches to my local > rails installation than I''d like to and I have found no way to keep the > changes under version control. -- But I really don''t want to learn yet > another VCS, I''ve only recently switched from CVS to subversion.I don''t personally use SVK, but the changes might not be that big - SVK uses Subversion under the hood, so knowledge about SVN should port pretty easily. Else, you''ll need to do vendor branch management yourself, with all the headaches. Sorry for not getting a better answer for you. Ball''s still up in the air, though. Somebody might come up with a better idea. Bye ! François
On Sep 29, 2005, at 4:22 PM, François Beausoleil wrote:> > Michael Schuerig said the following on 2005-09-29 15:57: > >> I''ve got the same response, on the subversion mailing list no >> less, when I asked about the same problem. I have applied more >> patches to my local rails installation than I''d like to and I have >> found no way to keep the changes under version control. -- But I >> really don''t want to learn yet another VCS, I''ve only recently >> switched from CVS to subversion. >> > > I don''t personally use SVK, but the changes might not be that big - > SVK uses Subversion under the hood, so knowledge about SVN should > port pretty easily. > > Else, you''ll need to do vendor branch management yourself, with all > the headaches. > > Sorry for not getting a better answer for you. Ball''s still up in > the air, though. Somebody might come up with a better idea. >I just got svk up and running, and it does exactly what I want. Thanks, I wasn''t aware of this tool. I also found a blog entry by Scott Laird about it here: http://scottstuff.net/blog/articles/2005/07/07/distributed- development-with-svk> Bye ! > François > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Thursday 29 September 2005 22:22, François Beausoleil wrote:> Michael Schuerig said the following on 2005-09-29 15:57: > > I''ve got the same response, on the subversion mailing list no less, > > when I asked about the same problem. I have applied more patches to > > my local rails installation than I''d like to and I have found no > > way to keep the changes under version control. -- But I really > > don''t want to learn yet another VCS, I''ve only recently switched > > from CVS to subversion. > > I don''t personally use SVK, but the changes might not be that big - > SVK uses Subversion under the hood, so knowledge about SVN should > port pretty easily. > > Else, you''ll need to do vendor branch management yourself, with all > the headaches.I''m tracking the edge and am doing an svn up at least once a day. Otherwise my most important patch[*] would be obsolete in no time. Doing a vendor branch each time looks prohibitive. Also, I''m not yet so very comfortable with subversion that I can handle all this easily. Michael [*] Let me pander it again: http://dev.rubyonrails.org/ticket/2172 -- Michael Schuerig Life is just as deadly mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org As it looks http://www.schuerig.de/michael/ --Richard Thompson, Sibella
On 9/29/05, Joseph Hosteny <jhosteny-ee4meeAH724@public.gmane.org> wrote: <snip>> I suppose the pain is that I need to keep a copy of the public repo > around from when I first imported it to use to generate the later > patches. Is this the best way to go about this?It should be fairly easy to automate pulling patches from vendor repos and applying them to your local repos using Rake or a shell script. Obviously, you would have some manual conflict resolution to do on occaision. Ken
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 29, 2005, at 11:39 AM, Jeremy Kemper wrote:> On Sep 29, 2005, at 11:14 AM, François Beausoleil wrote: > >> Joseph Hosteny said the following on 2005-09-29 12:12: >> >> Do you know about SVK[1] ? It manages the merging part of vendor >> code all by itself - less headache for you. >> > > Agreed. Managing vendor branches is a dream with svk! (And so > much more.) > > http://svk.elixus.orgDoes it do merge tracking? This is the most painfully missing feature from svn for me. - --Steve -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDPGIennOWIarjHBkRAk7CAJ0aVYWm/MGQVKK68YuvR3NHv1RbagCfcd/X 00BSvxySP70BPcNJz3aWoFw=yDc0 -----END PGP SIGNATURE-----
On Sep 29, 2005, at 5:52 PM, Stephen Waits wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Sep 29, 2005, at 11:39 AM, Jeremy Kemper wrote: > > >> On Sep 29, 2005, at 11:14 AM, François Beausoleil wrote: >> >> >>> Joseph Hosteny said the following on 2005-09-29 12:12: >>> >>> Do you know about SVK[1] ? It manages the merging part of vendor >>> code all by itself - less headache for you. >>> >>> >> >> Agreed. Managing vendor branches is a dream with svk! (And so >> much more.) >> >> http://svk.elixus.org >> > > Does it do merge tracking? This is the most painfully missing > feature from svn for me. >It looks like it, yes, as long as the branch is created via an ''svk cp'' command. That means I''m a little stuck right now - my subversion repository is on TextDrive, since I''d like to use SwitchTower to deploy. I was going to try to do an ''svk mirror'' of Typo (as the trunk), and my subversion copy from TextDrive (as the branch), then ''svk smerge'' from the trunk to my branch (while working in a repo checked out from local on my machine at home). I think to do what I want I really need svk running on TextDrive so I can setup the subversion repository there as needed.> - --Steve > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (Darwin) > > iD8DBQFDPGIennOWIarjHBkRAk7CAJ0aVYWm/MGQVKK68YuvR3NHv1RbagCfcd/X > 00BSvxySP70BPcNJz3aWoFw> =yDc0 > -----END PGP SIGNATURE----- > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 29, 2005, at 2:40 PM, Michael Schuerig wrote:> On Thursday 29 September 2005 22:22, François Beausoleil wrote: >> Michael Schuerig said the following on 2005-09-29 15:57: >>> I''ve got the same response, on the subversion mailing list no less, >>> when I asked about the same problem. I have applied more patches to >>> my local rails installation than I''d like to and I have found no >>> way to keep the changes under version control. -- But I really >>> don''t want to learn yet another VCS, I''ve only recently switched >>> from CVS to subversion. >> >> I don''t personally use SVK, but the changes might not be that big - >> SVK uses Subversion under the hood, so knowledge about SVN should >> port pretty easily. >> >> Else, you''ll need to do vendor branch management yourself, with all >> the headaches. > > I''m tracking the edge and am doing an svn up at least once a day. > Otherwise my most important patch[*] would be obsolete in no time. > Doing a vendor branch each time looks prohibitive. Also, I''m not > yet so > very comfortable with subversion that I can handle all this easily.I can''t recommend svk enough for exactly this scenario. For any work beyond simple fixes, I make a local branch of the remote svn trunk (cool!) and do the coding and testing locally. When the trunk changes but I''m not done with my feature, I can merge the changes since my last merge with a single command. When I''m done and everything tests out, I can push back to the remote svn trunk with a single command, either as a real commit or as a patch! Quickstart: # Mirror the remote svn repos to my local svk depot. You''ll see paths # beginning with // in svk a lot -- they are paths within the local depot. svk mkdir //rails svk mirror http://dev.rubyonrails.org/svn/rails //rails/mirror # Check out the mirror and play with it if you like. Working on this # checkout with the svk commands is like working with a proxy for the # real repository: ''svk commit'' sends the commit back to the mirror, etc. svk co //rails/mirror/trunk cd trunk/activerecord vi CHANGELOG svk commit -m "..." CHANGELOG # Make a local branch of the mirrored trunk to develop a feature. # Note that my use of //rails/mirror/trunk as the path for the mirrored # svn repository and //rails/tickets/ticket-num for ticket-fix branches # is arbitrary -- this is a convention similar to the way svn encourages # tags, branches, trunk, etc. svk mkdir //rails/tickets svk cp -m "Branching for ticket #2172" //rails/mirror/trunk //rails/ tickets/2172 vi foo svk commit foo svk move foo bar svk rm baz etc. # I''m not done yet but decide to call it a night. In the morning a bunch # of new changesets have gone into svn trunk. Merge them with this branch. svk pull # Do more edits and commits. Write the tests. The feature is done. # # Pull changes from trunk again so the patch is current. (NOTE that svk # knows when we''ve merged branches, so only changes since the last merge # are pulled! This is *the* most aggravating thing about branch # management in svn.) svk pull # Now we''re ready to create the patch. This creates # ~/.svk/patch/ticket-2172.1.patch svk push -P ticket-2172.1 # Or write the patch to stdout. svk push -P - > ~/ticket-2172.patch # Still waiting for patch to be applied, but trunk has been updated. # Plus we want to improve the feature. svk pull ... edit ... svk commit svk push -P ticket-2172.2 # Finally the patch is applied. But a bug turns up we need to fix. svk pull ... edit .. svk commit svk push -P ticket-2172.3 # The patch has been applied for a while with no further issues. # Archive the branch. svk mkdir //rails/tickets/closed svk mv //rails/tickets/2172 //rails/tickets/closed/ # Or just remove it. svk rm //rails/tickets/2172 The online manual is adapted from the svn book: http://svkbook.elixus.org/nightly/en/svk-book.html An recent interview with its creator: http://www.oreillynet.com/pub/a/network/2005/09/20/painless- merging-with-svk.html I didn''t mean this thread to become an svk advertisement, but there you have it ;-) Best, jeremy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDPHAlAQHALep9HFYRArbyAJ49TMUo81UeYVGHwXqrY2XRDSy3PQCgnr/N bkJ1uCaNaFEOnt0DDqQlxXA=mx4c -----END PGP SIGNATURE-----
On Thursday 29 September 2005 23:50, Ken Barker wrote:> On 9/29/05, Joseph Hosteny <jhosteny-ee4meeAH724@public.gmane.org> wrote: > <snip> > > > I suppose the pain is that I need to keep a copy of the public repo > > around from when I first imported it to use to generate the later > > patches. Is this the best way to go about this? > > It should be fairly easy to automate pulling patches from vendor > repos and applying them to your local repos using Rake or a shell > script. Obviously, you would have some manual conflict resolution to > do on occaision.I''d happily use such a script if anyone writes it... Michael -- Michael Schuerig Nothing is as brilliantly adaptive mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org as selective stupidity. http://www.schuerig.de/michael/ --A.O. Rorty, The Deceptive Self
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 29, 2005, at 3:26 PM, Joseph Hosteny wrote:> It looks like it, yes, as long as the branch is created via an ''svk > cp'' command. That means I''m a little stuck right now - my > subversion repository is on TextDrive, since I''d like to use > SwitchTower to deploy. I was going to try to do an ''svk mirror'' of > Typo (as the trunk), and my subversion copy from TextDrive (as the > branch), then ''svk smerge'' from the trunk to my branch (while > working in a repo checked out from local on my machine at home).See entry at http://svk.elixus.org/?SVKFAQ regarding mirroring between remote repos. Regards, jeremy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDPHG9AQHALep9HFYRAni2AJ9NKUW0LieR/dkmGL4QLx8Dlss5LQCdEVa9 6SYSDszB6VIDf8Ub39VL/dc=RbXN -----END PGP SIGNATURE-----