[svk-users] right way to roll back a merge in the depot?

[Chia-Liang Kao]

> svk merge -c -REV /local /local  (where REV is the explicit revision
> number of the upgrade smerge)
>
> This undid the merge correctly.  First question:  Is that a remotely
> reasonable command to issue, with /local appearing twice?  It's a bummer
> I need to explicitly specify the revision to roll back there, but I
> guess it's not that big of a deal.  I expected to be able to do a
> "forced merge" between /tags/v1_1 and /local, if that makes sense.

that's right, for having local twice. basically it's playing the
reverse of REV on local to local, hence reverting the change.  "forced
merge" doesn't quite make sense from /tags/v1_1, especially if you've
committed or merged others stuff to local.  if you'd want to get local
back to the tag snapshot again, just rm local and cp again.

> svk up in the wc's, and I've rolled back.  Yay!
>
> Now, I'd like to upgrade to v1 again.  In this test, nothing changed in
> v1, not sure if that matters.
>
> svk smerge -C /branches/v1 /local
> Empty merge.
>
> Hmm.
>
> svk smerge --baseless -C /branches/v1 /local
> Empty merge.
>
> Hmm.
>
> Second question(s): I could probably get an explicit svk merge to work
> with the -REV syntax, but would that hose me later again?  What's the
> right way to do this?  At this point I just want to forget the whole
> rollback and continue on my merry way in /local with it being based on
> /branches/v1.  I can't get anything involving /branches/v1 and /local to
> work.

the reason is the merge -c -REV kept the merge tickets, as it assumes
you don't want to merge that revision again.  We might want an easier
to way to do the alternative.  but for now you can do a svk ps
svk:merge on local, with the content being the value of svk:merge on
the revision before the wrong upgrade.


Cheers,
CLK