Thread: [Module::Build] svk pulling
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Ken W. <ke...@ma...> - 2006-04-20 16:38:40
|
Hey, I'm having some kind of problem with SVK I'm not sure how to handle. I wanted to go into the release-0_26_branch and maybe make a bug fix, so I went to my working directory: % svk info Checkout Path: /Users/ken/src/Module-Build-svk-0.26 Depot Path: //mirror/module-build/branches/release-0_26_branch Revision: 1874 Last Changed Rev.: 1828 Mirrored From: https://svn.perl.org/modules/Module-Build, Rev. 5932 Copied From: /mirror/module-build/trunk, Rev. 1147 Merged From: /mirror/module-build/trunk, Rev. 1147 % svk mirror --list Path Source ============================================================ //mirror/module-build https://svn.perl.org/modules/Module-Build /module-build/mirror http://svn.perl.org/modules/Module-Build (Ignore that second mirror, I don't use it and I want it to go away.) When I perform "svk pull" in /Users/ken/src/Module-Build-svk-0.26 , I get notified of a lot of conflicts. I figure, whatever, I haven't ever made changes in this directory, so I "accept theirs" for all the conflicts, thinking that will just get me a fresh version of stuff. But then if I do "svk pull" again in the same directory, I get the same set of conflicts. Help? -Ken |
|
From: David G. <da...@hy...> - 2006-04-20 18:03:59
|
Ken Williams wrote: > Hey, > > I'm having some kind of problem with SVK I'm not sure how to handle. I > wanted to go into the release-0_26_branch and maybe make a bug fix, so I > went to my working directory: > > % svk info > Checkout Path: /Users/ken/src/Module-Build-svk-0.26 > Depot Path: //mirror/module-build/branches/release-0_26_branch > Revision: 1874 > Last Changed Rev.: 1828 > Mirrored From: https://svn.perl.org/modules/Module-Build, Rev. 5932 > Copied From: /mirror/module-build/trunk, Rev. 1147 > Merged From: /mirror/module-build/trunk, Rev. 1147 > > % svk mirror --list > Path Source > ============================================================ > //mirror/module-build https://svn.perl.org/modules/Module-Build > /module-build/mirror http://svn.perl.org/modules/Module-Build > > (Ignore that second mirror, I don't use it and I want it to go away.) svk mirror --detach /module-build/mirror svk rm /module-build/mirror The latter might cause problems since you appeared to have merged from it. > When I perform "svk pull" in /Users/ken/src/Module-Build-svk-0.26 , I > get notified of a lot of conflicts. I figure, whatever, I haven't ever > made changes in this directory, so I "accept theirs" for all the > conflicts, thinking that will just get me a fresh version of stuff. But > then if I do "svk pull" again in the same directory, I get the same set > of conflicts. I believe "svk pull" is shorthand for "svk update -sm". It's really designed for when you're working on something checked out from a local copy of a mirrored directory -- you want to sync the mirror, then smerge the changes from the mirror to the local copy, then update your checkout with the local copy. However, you're operating directly against the mirrored directory, so when you pull, I think the smerge is going back to the trunk (i.e. where the mirror directory was last merged from) and trying to pull in changes from that. Since you haven't checked in the changes (and you probably shouldn't!) I suspect that each pull is finding the differences from the trunk and the 0.26 branch. When you're working directly from a mirrored directory, I think you really just want to do "svk update -s" which syncs the mirror and then updates your working files from the mirror. Frankly, I think much of the benefit of svk comes from using local copies. You can check in your own incremental work in the local copy without affecting what anyone else upstream sees. Once you're happy with your changes, you can then merge it all back upstream, either individually ("svk push") or all together ("svk push -l"). Here's how I'd work: svk mi https://svn.perl.org/Module-Build/ //mirror/Module-Build svk sync //mirror/Module-Build svk cp -m "local copy" //mirror/Module-Build/branches/release-0_26_branch //local/Module-Build-0_26_branch svk co //local/Module-Build-0_26_branch Module-Build-0.26 Hope that helps, David Golden |
|
From: Ken W. <ke...@ma...> - 2006-04-20 18:23:54
|
On Apr 20, 2006, at 1:03 PM, David Golden wrote: > Ken Williams wrote: >> Hey, >> I'm having some kind of problem with SVK I'm not sure how to >> handle. I wanted to go into the release-0_26_branch and maybe >> make a bug fix, so I went to my working directory: >> % svk info >> Checkout Path: /Users/ken/src/Module-Build-svk-0.26 >> Depot Path: //mirror/module-build/branches/release-0_26_branch >> Revision: 1874 >> Last Changed Rev.: 1828 >> Mirrored From: https://svn.perl.org/modules/Module-Build, Rev. 5932 >> Copied From: /mirror/module-build/trunk, Rev. 1147 >> Merged From: /mirror/module-build/trunk, Rev. 1147 >> % svk mirror --list >> Path Source >> ============================================================ >> //mirror/module-build https://svn.perl.org/modules/Module-Build >> /module-build/mirror http://svn.perl.org/modules/Module-Build >> (Ignore that second mirror, I don't use it and I want it to go away.) > > svk mirror --detach /module-build/mirror > svk rm /module-build/mirror > > The latter might cause problems since you appeared to have merged > from it. Not that I'm aware of, but it's possible. After I perform these steps, I can just delete all of ~/.subversion/ module-build , right? Or should I be afraid of that? >> When I perform "svk pull" in /Users/ken/src/Module-Build- >> svk-0.26 , I get notified of a lot of conflicts. I figure, >> whatever, I haven't ever made changes in this directory, so I >> "accept theirs" for all the conflicts, thinking that will just get >> me a fresh version of stuff. But then if I do "svk pull" again in >> the same directory, I get the same set of conflicts. > > I believe "svk pull" is shorthand for "svk update -sm". It's > really designed for when you're working on something checked out > from a local copy of a mirrored directory -- you want to sync the > mirror, then smerge the changes from the mirror to the local copy, > then update your checkout with the local copy. So in this case I probably just want "svk update"? If I want to get myself up to date in a mirrored copy I do "svk update", and if I'm in a local copy I do "svk pull"? > > However, you're operating directly against the mirrored directory, > so when you pull, I think the smerge is going back to the trunk > (i.e. where the mirror directory was last merged from) and trying > to pull in changes from that. Since you haven't checked in the > changes (and you probably shouldn't!) I suspect that each pull is > finding the differences from the trunk and the 0.26 branch. > > When you're working directly from a mirrored directory, I think you > really just want to do "svk update -s" which syncs the mirror and > then updates your working files from the mirror. > > Frankly, I think much of the benefit of svk comes from using local > copies. You can check in your own incremental work in the local > copy without affecting what anyone else upstream sees. Once you're > happy with your changes, you can then merge it all back upstream, > either individually ("svk push") or all together ("svk push -l"). That makes sense. I think I don't need this very often on the M::B project since a lot of my changes are either pretty small or I try to check them in incrementally with no breakage, but sometimes it could be valuable. -Ken |
|
From: David G. <da...@hy...> - 2006-04-20 18:32:10
|
Ken Williams wrote: >> svk mirror --detach /module-build/mirror >> svk rm /module-build/mirror >> >> The latter might cause problems since you appeared to have merged from >> it. > > Not that I'm aware of, but it's possible. > > After I perform these steps, I can just delete all of > ~/.subversion/module-build , right? Or should I be afraid of that? I'm not sure what that directory holds. > So in this case I probably just want "svk update"? If I want to get > myself up to date in a mirrored copy I do "svk update", and if I'm in a > local copy I do "svk pull"? That's right, though you want "svk update -s" to sync the mirror first before the update. David |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X