Best practices for moving/renaming files in TortoiseSVN

[BertMcMahan]

So I'm in my first "real project" using source code control- I'm using TortoiseSVN. So far I quite like it, and of course wish I'd been doing it for years 🙂

My question is regarding moving and renaming files. In this project I sometimes end up changing my mind about how I want a function to be used, and end up renaming it. Usually something simple; for example, "Edit test settings" to "Edit global test settings" or something. Sometimes it ends up being a folder that gets moved and a dozen VI's get affected (their path changes but their name doesn't).

When I commit this change to SVN, it detects the new file as being added and the old one as missing. I don't see a way to tell it that I renamed something apart from manually doing that to each file within the repo browser, but that means the LabVIEW project goes nuts the next time you try to open it and it can't find the old file. I've had bad experiences trying to batch-rename files like that, so I always do it within the Project environment.

It's simple to just mark the old files as "deleted" in SVN, then add the new ones. This works for a few small unimportant VI's here and there, but I'm wondering if there's a better way. Note that I don't have SVN integrated into my project- is there some integration mechanism that would automatically notify SVN that I renamed a file from within the project? If so how might I set that up?

[550nm]

Right-click; \TortoiseSVN\Rename

Then Commit the Parent folder!

Cheers.

[GerdW]

Hi Bert,

When I commit this change to SVN, it detects the new file as being added and the old one as missing.  … LabVIEW project goes nuts the next time you try to open it

Never rename VIs (or other stuff) outside the corresponding LabVIEW project!

Solution: do the renaming inside LabVIEW project and live with "new"/"missing" commits. (I never had SVN troubles because of them; the sanity of my LabVIEW projects is more important than disk space of the SVN server…)

[Yamaeda · Accepted solution]

In the commit, select the two files, r-click -> Repair Move to get a correct log.

/Y

[BertMcMahan]

 Jiminy crickets Yamaeda, didn't know that was an option.

For future reference to others, if you do an Add and then try this trick, it won't work- you need to leave the renamed file unversioned, then ctrl-click both elements, right click, and Repair Move.

Thanks so much. I figured there HAD to be a straightforward way to do this without screwing up my project references and relinking things.

[Bob_Schor]

Here are a couple of "rules" that will save you a lot of grief and worry when using SVN and LabVIEW Project.

• Never attempt to "fix" an SVN problem by using the RepoBrowser.  You should do everything possible to avoid using the RepoBrowser -- it is just too dangerous to mess with the Repository directly.
• Similarly, make changes to the Project and its files from the Project Explorer window (only).  In particular, if you want to do a Rename of a File, the safest way is to locate the file in the Project, right-click it, and choose Rename (or Save As ...).  Note that if you "rename it to another folder", you'll have to manually drag the Explorer entry to the new Folder.  Also note that I'm talking about the "Items" tab, not the Files tab.  [To be honest, I almost never use the Files tab, largely because I don't trust doing things that don't "break" the Project].
• The way Subversion works is that a Rename necessarily is a Delete + an Add.  If you look up the Rename command in the Help, you'll see this explained.  So don't worry about it!

So my set of Best Practices for moving/renaming files in TortoiseSVN (in the context of talking about a LabVIEW Project) is simple -- Never move or rename (LabVIEW) files in TortoiseSVN.  Always move/rename LabVIEW Files within LabVIEW Project (the "Items" View), then Commit the changes to SVN.

Bob Schor

[550nm]

Sorry for not reading your post carefully. I manage the source-tree without a LabVIEW project, but use a project (later) for creating EXEs and Installers. I just live with the occasional pain of relinking after SVN rename. It may not be a "best practice" (as defined by consensus) but it works for me!

[BertMcMahan]

Thanks Bob. I've been mainly doing that- anytime I tried to do something outside of the Project environment it ended in heartache.

Regarding the rename being a Delete + Add: is there a difference between a manual Add then a Delete, as opposed to doing the "Repair Move" (which I can see results in a Delete + Add)?

I would suspect that the Repair Move command would do a Delete/Add, but that it would "know" that "File A-2" is a renamed version of "File A" and could trace the previous versions that way. Is that correct?

[Bob_Schor]

Sorry, I wasn't clear.

Do everything to your LabVIEW Project and its files in LabVIEW using the Project Explorer.  The only thing you do in Tortoise SVN is a Commit (when you have finished or want to "pause") and an Update (when you start).

You should not be doing an "Add" and "Delete", or a "Repair Move" (whatever that is) when dealing with LabVIEW and its Project Explorer.  That way lies madness (and the risk of corrupting your Repository).

Bob Schor

[Bob_Schor]

Wow.  Ever since the LabVIEW Project was introduced, I've been using it for everything except the "one-off" simple VIs to test something ("How do I do XXX in LabVIEW"), writing a piece of code for the Forum, or something similar that I'll almost immediately delete.  Certainly anything that involves more than one VI + 3 sub-VIs and a TypeDef or two always gets a Project as the first step ...  This has really simplified my LabVIEW Development effort, and is one of the first things I try to impress on those I advise ...

Bob Schor