Retroactive branching. Folder roll-back.
From: Ed Zarkowski <wowbagger58-forums_at_yahoo.com>
Date: Mon, 21 Sep 2015 12:48:36 -0700 (PDT)
I've got myself into a bit of a mess.
I'm using TortoiseSVN in a singler-user environment (repositories on a local drive).
I have multiple repositories, using different "layout schemes".
My "library" repository has a trunk/branches/tags organization at the root level, since library code is potentially interrelated. The root library working folder, of course, has the sole .svn sub-folder in the Library hierarchy.
Foolishly, I began a significant revamping of one library, call it "Foo" (i.e., a "Foo" sub-folder within the Library folder hierarchy) without first creating a branch (i.e., I stupidly committed my work into the trunk).
Let's say I decided to "Flarkize" Foo.
After a while, I realized that Flarkenizing Foo was very likely unnecessary. There is a much simpler means of accomplishing my goal.
I'd like to revert to the pre-Flark version of Foo.
However, I'd also like to keep the Flarkized code as a branch, as it were, in case I ever do decide to use it.
I then further mucked things up, as below:
Using Repo Browser, I changed the name of "Foo" folder (in the repository), to
I also changed the relevant working folder name from Foo to Foo_Flarkize_Aborted.
I then created a Foo folder, and restored Pre-Flark content to it (from a 7-Zip file, actually).
Using File Explorer, examining Foo and Foo_Flarkize_Aborted revealed the following:
Subfolder Foo has TortoiseSVN icon overlays.
Subfolder Foo_Flarkize_Aborted has no icon overlays.
Furthermore, the icon overlays for "Foo" correctly indicate status relative to repository folder "Foo_Flarkize_Aborted".
In other words, the File Explorer view "looks" just as it would have if I had simply replaced the content of working folder "Foo" with the content from the 7-Zip file.
I don't understand how TortoiseSVN associates working folder Foo with repository folder Foo_Flarkize_Aborted.
I'm speculating that the .svn metadata for my Library contains a reference to the root/trunk of my Library repository, but no direct "lower level" references.
For example, consider the situation prior to my Flarkize efforts.
I would have thought that the .svn metadata contained no "direct" reference to repository folder "Foo" ("linking it" to Working folder "Foo").
Rather, that the association between repository folder "Foo" and working folder "Foo" was implied by the repository hierarchy (and, of course, the association of the working folder "Library" with the trunk within the Library repository).
My questions are these:
1) How is my working copy "Foo" able to "refer to" the Foo_Flarkize_Aborted repository folder?
When a repository folder is renamed, does TortoiseSVN remember the original name, and somehow use it?
2) More importantly, is there some way to extricate myself from this mess?
Specifically, create a situation in which the Library repository contains a "Foo_Flarkize_Aborted" branch (reflecting the current trunk/Foo head), and the trunk/Foo head is rolled back to a Pre-Flark state?
A) If I rename the repository folder back to "Foo", will it be, essentially, as if I had never renamed it?
I believe I backed up the repository (using svnadmin hotcopy) just prior to beginning the Flark work.
However, I've also made non-Flark changes (outside the Foo folder) within the Library hierarchy, since that time.
I'd like to get back to the situation before I renamed the repository folder (at least, I think I do).
Could I restore the Library repository from my backup, keep the Foo working folder (from my 7-Zip), which would then match the repository, and commit the library hierarchy (in other to commit non-Foo changes)?
Any advice appreciated. Even, "The trunk is sacred. Create a branch, you miserable vomitous mass, before modifying code".
------------------------------------------------------
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
|
This is an archived mail posted to the TortoiseSVN Users mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.