Re: [Module::Build] svk pulling

[Ken W. <ke...@ma...>]

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