0

I have seen other similar post and answers. But my situation is more restricted as following:

Branch repo/A has child branches repo/B and repo/C. C pushed/merged new foo.c to A. Then B pull/merged to get foo.c then pushed/merged other changes. Let's say B's revision changed from 10 to 11 after the pull. Now everything is messed up for branch B so I want B to go back to revision 10 and take as the pull never happened.

So I looked through those post and figured out to solve the problem by following step:

  1. svnadmin dump $(repo/B) -r 0:10 | svnadmin load $(newRepo/B)
  2. now I want to use the original repo url so:

    2.1) back up to prevent anything messing up: svnadmin copy $(repo/B) $(repo/B_backup)

    2.2) copy over new: svnadmin copy $(newRepo/B) $(repo/B);

  3. Now I want the UUID to be the same and I don't have the svnadmin setuuid because the svn version is 1.4. So:

    3.1)Before step 1, svn info $(repo/B) to record original UUID

    3.2)After step 2, open log of $(repo/B) somewhere then copy the original UUID to it

Now $(repo/B) has revision 10 and same UUID.

My question is

  1. After all this done, will branch A and C change also?

  2. Is there anything missing in my solution cause I don't want to mess it up again? Or better way to do so?

Thanks

Linghua Jin
  • 570
  • 2
  • 6
  • 22
  • Don't dump/restore the whole repo! Just svn delete B from HEAD, then svn copy it from your last good revision. – Blorgbeard May 17 '13 at 02:17
  • So you are saying even I only dump/load B, the whole A will be dump/load? – Linghua Jin May 17 '13 at 02:18
  • Well, maybe I'm confused - how many repos do you have? I'm assuming you have one repo, and A B and C are folders/branches inside the repo? – Blorgbeard May 17 '13 at 02:20
  • ok, so don't use `svnadmin dump` then - the svnadmin tool is for whole-repo maintenance, not every day reverting a subtree – Blorgbeard May 17 '13 at 02:25

1 Answers1

1

Instead of using svnadmin to dump and restore the entire repo(!), you should simply delete/copy the subtree:

C:\>svn delete -m "this version went bad" svn://server/repo/B

Committed revision 12.

C:\>svn copy -m "restore good version" svn://server/repo/B@10 svn://server/repo/B

Committed revision 13.

In general, don't use svnadmin if you can avoid it. It's really for administration tasks - not normal source control operations like branch/merge/rollback.

Blorgbeard
  • 101,031
  • 48
  • 228
  • 272
  • Thanks for your suggestion. If I did your way, then repo/B become revision 13. If I do catch on repo/B again, could I still get the foo.c that thrown by C earlier? – Linghua Jin May 17 '13 at 02:37
  • I'm not sure what you mean by "throw" and "catch" in this situation. repo/B becomes revision 13, but it's an exact copy of revision 10, so everything should be exactly the same. – Blorgbeard May 17 '13 at 02:38
  • OK. Now I have another concern: if before repo/B revert back, it already merged something(let's say bar.c) to repo/A. Now repo/B revert to the state that B hasn't merged bar.c to repo/A but repo/A already got bar.c. Then they are out of sync. – Linghua Jin May 17 '13 at 03:27
  • Can I remove bar.c in repo/A so that the next time repo/B can still merge bar.c to repo/A? – Linghua Jin May 17 '13 at 03:28
  • When you reverted repo/B, you didn't change any files outside repo/B. If a file was copied from B to A, then that file is still the same. You could delete `bar.c` from repo/A and then copy it again from repo/B? – Blorgbeard May 17 '13 at 03:36
  • OK. My final question is that if there are working directory checked out before repo/B reverted back, are those working directory broken after repo/B reverted(basically got replaced by another repo/B)? Or as long as the name "repo/B" is same, those working directory can still work as normal just like two more commit happened(rev 12 and rev 13)? – Linghua Jin May 17 '13 at 03:44
  • The working directories are fine, they're still linked to repo/B - if you update them, they will revert too. Unless there are uncommitted changes in them - then you might get a conflict. – Blorgbeard May 17 '13 at 04:46
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/30102/discussion-between-linghua-jin-and-blorgbeard) – Linghua Jin May 17 '13 at 05:20