[svk-devel] unexpected behavior with pull

[Jared Hardy]

On 3/9/07, Jonathan Rockway <jon at jrock.us> wrote:
> Anyway, I'm still on the train and I decide I really don't want to break trunk
> when I push, so I svk
> cp //local/project/trunk/MyApp //local/project/branches/MyApp-broken and then
> svk sw //local/project/branches/MyApp-broken.  I then proceed to commit until
> I get home, at which point I connect to my network and svk push.
>
> Oops.  I pushed MyApp-broken into trunk.  When I push trunk (not sure how I do
> this now), I then push the MyApp-broken stuff back up to the server's trunk,
> breaking everyone's build and getting lots of hate mail as a result.  What I
> really wanted to happen was for a MyApp-broken branch to get created on the
> server and then to have my //local changes pushed to it.
>
> Basically, I want //local and //mirror to be EXACTLY THE SAME after a push or
> pull.  How can I get this to happen?

Wow, I didn't know that would happen. Thanks for the heads-up -- that
would cause a lot of headache here too. I wonder, are you able to "svk
cp //mirror/project/branch-old //mirror/project/branch-new" while
offline, as a work-around?

> Another related problem:
>
> svk cp //mirror/huge-project/trunk //local/huge-project/trunk
> svk cp //mirror/huge-project/branches //local/huge-project/branches
> svk co //local/huge-project huge-project
> cd huge-project
> svk pull # doesn't work

I agree that it would be more intuitive for svk to break the pull
operation up, into one pull per disconnected branch copy, rather than
failing. I think that trying to pull from a folder that contains two
separate copies underneath it might be dangerous otherwise.

> I think a lot of people want this to work -- they frequently work on trunk and
> branches, but never touch the tags (because they take a lot of disk space,
> and ... shouldn't be touched anyway).

Now this is the part I disagree with a bit. Tags in Subversion/SVK are
just like read-only branches, so they should take very little
additional hard drive space in SVK, compared to any other kind of
branch. Making one big checkout of a folder above multiple branch
copies is just wasteful no matter how you look at it, so doing the
same with tags just seems a little redundant, and calling that the
culprit of the disk waste is a bit slanted. Having a separate checkout
per branch is more appropriate, or using the "-N" non-recursive flag
on the top-level checkout, makes more sense.
    If the first use-case problem (cp //local/1 //local/2, push
//local/2) was fixed, I might say having tags in the //local copy
might be handy for creating new tags, or renaming old tags. Also, if
commands like "svk cp /brach1-checkout/thing /branch2-checkout/."
worked properly, there would be no need for monolithic multi-branch
checkouts. For now, I am working around that issue by using a script
that converts all such commands to "svk cp
//local/project/branch1/thing //local/project/branch2/.".

    Just my 2cents,
    Jred