LabVIEW
Best practices for moving/renaming files in TortoiseSVN
Solved!
No I followed you Bob, I meant when you go to do your commit within Windows, my normal process was to do a right click on the folder, then do an Add, then a Commit. Within the Commit window I'd find the items marked Missing and hit Delete, which marks them as Deleted. All is then well.
The "Repair Move" is done within the Commit window; highlight the two items (the one marked Missing and the one marked Unversioned) then right click and select "Repair Move". It will then mark the Missing item as Deleted, and the Unversioned item as Added, but what I'm wondering is if it ONLY does a delete/add or if it also keeps track of the item history (so it maintains version continuity).
Not sure if the question even really makes sense but that's what I'm going for.
wrote:
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?
That's what it says in the TSVN help, I believe. It maintains the history for that file.
wrote:
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
"Repair Move" is fine, as long as you can keep track of which "added" file replaced which "deleted" one. It is arguably better to do it this way, since the history of the file will be intact. This is the standard way of letting TSVN know a file has been renamed without using its renaming function.
wrote:
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.
Yes, i've had the same thoughts several times, but then i realize SVN is made by developers for developers and they _must_ have had this happen to them. So some googling and fiddling about and you often find a neat solution.
You can theoretically go the other way, moving a file with r-drag and select svn-move from the menu. That will mess up the project way more than it's worth, so change/move from inside LV and Repair move is the better solution.
/Y
wrote:
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
Repair move is simply an instruction to SVN that a file has been moved/renamed instead of being 2 different files (1 added, 1 deleted). Thus if you check out an old version name changes will be tracked and applied correctly.
/Y
