Home/ Questions/Q 7795915
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-01T23:12:34+00:00

I ended up having a few Tortoise and/or Subversion malfunctions, and somehow ended up

  • 0

I ended up having a few Tortoise and/or Subversion malfunctions, and somehow ended up with several versions of the same project:

...\Projects\
    MyProject
    MyProject(1)
    MyProject(2)

MyProject(2) is the one that is the “true” one, and is thus the one I want to keep.

I cut and pasted both MyProject and MyProject(1) to a “holding tank” for eventual deletion, so that I now have:

...\Projects\
    MyProject(2)

Now I want to change the name MyProject(2) to MyProject, but I’m afraid to – Tortoise/Subversion is so picky about everything (IOW, it works as intended) that I’m afraid that if I change the name, everything will get all hosed up.

Am I being unduly paranoid? Should I just go ahead and rename it, or does Tortoise/SVN have some “refactor” ability that will make that a safe operation, or…?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You are not being truly paranoid, once you commit, you have that commit forever, it’s worthwhile to take the time to make sure your commit is right. Otherwise, you’ll still have to spend that same amount of time to do the “fix” commit.

    You probably “saved” through the gui some set of items multiple times, and the “window manager” has an option to not overwrite files by adding (1) and the like. If so, odds are good that only one of the branches is actually under revision control. Do a 

    svn status

    in a few directories to determine if these sub-directories have only been copied in place on your system, have been copied and added on your system, or have been copied, added and committed to the repository.

    If they have only been copied in place, discover which “copy” is the best, and move the contents of that copy to the “correct” location, and delete the others. Then svn add whatever is necessary and commit.

    If they have been copied and added, discover which “copy” is the best, svn revert everything you do not intend to commit, move the contents of the “best” copy to the correct locations, and delete the unneeded files. Then svn add whatever is necessary and commit.

    If they have been copied, added, and commited, then svn delete stuff that’s “in the way”, svn commit, svn move the right stuff into it’s correct location, svn commit, svn delete the other unneeded files, and svn commit.

    There are many other variations on how to fix this (some much better than I have demonstrated), but hopefully the above examples will get you thinking along the right paths. My examples involve more steps, to keep things simple.

    • 0