[svk-users] push /pull problem
David Kaufman
david at gigawatt.com
Mon Apr 28 15:44:35 EDT 2008
Hi Jesse,
"Jesse Vincent" <jesse at bestpractical.com> wrote:
>
> On Apr 12, 2008, at 7:52 PM, David Morton wrote:
> > I have mirrored a remote repo, and then checked out a branch from the
> > mirror:
> > [snip]
> > When I push a set of changes, it [...]
> > tries to merge https://www.maiamailguard.com/svn/trunk into my
> > branches/1.0 path. Did I do something wrong?
> >
>
> Likely, you want to
>
> svk cp //mirrors/maia/branches/1.0 //local/maia-1.0
>
> and then work on the local branch. What you've been doing up to now is
> working on a direct checkout of the mirrored branch. In the svk world
> "mirrored" branches should be exact clones of the remote trees which
> they mirror. So any change should be applied to the remote tree first
> and then copied down.
>
> "svk help intro" should describe the "right" workflow.
>
> Does that make sense?
It didn't make sense for me, either. The "right" workflow seems wrong to
me. Whether I've checked out the entire repo (trunk, branches, tags and
all) or I've checked out just a particular branch, it's alarming and
surprising to me as a user that, when I try checking my changes in, onto a
branch, svk tries to merge the trunk to the branch... I see is as a bug.
pull-ing from, and push-ing to, a branch should only read data from, or
apply changes to that branch, regardless of whether the trunk is local or
remote... but maybe i just need a "pull-branch" command or something to
DWIM.
I know svk can do a lot more than svn but (I think) I'm a member of a large
class of users who just want to use svk to mirror our work svn repos
locally (when we go home), to be able to do "offline" commits (even to
branches, and expect those commits to stay on those branches), and
essentially time-shift all our work back to the real world after we've come
down off the mountain with our laptops, and need to sync up with the real
world after regaining net access.
To do my work I often need to switch branches while offline to, say, fix a
bug on the trunk and then backport the fix to a previously released
version, and commit it to the released version' bug-fixes branch. svk does
not support me in this. I'd have to mirror each branch of the remote repo
*separately* (keeping track of newly branches myself) just to "hide their
lineage" from svk so it doesn't try to pull the trunk into my branch when i
pull, or worse, merge my branch back up to trunk when I commit to them,
then later try to push them to the remote branch.
I've stopped using svk long ago over this very issue, having realized that
mine is just a non-supported use case, but I like to read the list and post
these little me-too's whenever someone re-reports this as a bug. It's
clear from the replies from the dev team that you guys don't acknowledge
the behavior we're seeing as a problem, but to us it is, if not a bug,
certainly a missing (and misunderstood!) feature. I haven't heard from
anyone (and doubt I ever will) who thinks of it as a *feature* that when
they commit to a checkout of branch and (only if the local mirror also
contains the trunk) use push or pull to (intentionally, mind you) trigger a
merge of the remote branch to the remote trunk. But hey, there might be
people who want to do this. All I'm saying is I haven't heard from them,
while i keep hearing from users like me who expect push or pull to be
useful (in a non-catastrophic sense) and do the same thing whether the
local mirror is of just a single branch, or the who remote repository.
We assume that what we want to do will 'just work', and when it doesn't, it
fails in this spectacularly surprising way. I guess you guys, who've done
the awesomely wonderful job of *creating* svk, simply don't use svk this
way and can't understand why our minority of users would ever try to do
such a thing, and wonder why the oft-cited workaround is completely
unhelpful to us and that's why this bug is always dismissed as user error.
That's disappointing, but I'm still listening, and waiting to see if any
one ever decides to "fix" it (if it is a bug in push/pull) or if, more
likely (it is a missing feature) and add a new set of svk $verbs that do
what we need, which is: "*just* move our local branch changes to the remote
branch" and "*just* move remote branch changes to our local branch"
(without merging any branches to or from the trunk, please -- thank you),
so I can jump back into using svk :-)
Thanks for listening!
-dave
More information about the svk-users
mailing list