Source control (TFS) and moving project's local location?

This forum is for all Flare issues related to using Source Control.
Post Reply
jsandora
Propeller Head
Posts: 94
Joined: Thu Jun 23, 2011 5:56 am
Location: Boston, MA

Source control (TFS) and moving project's local location?

Post by jsandora »

Here's the quick rundown of the problem we're facing here.

I was the only tech writer on staff when we started using Flare, so set up my projects in the My Documents folder on my local PC. This includes a Style Guide that all projects are linked to via Global Project Linking. Everything is bound to TFS source control.

We've since hired a new tech writer. He downloaded all the projects from source control, also located in his My Documents folder.

The problem we just noticed is that the path to the My Documents folder contains our usernames (C:\Users\jsandora\Documents\help files\madcap\StyleGuide). This is causing a problem with the Global Project Linking since the path located in the Import file for the Style Guide is the one on MY computer - so it contains my username. So when he kicks off new builds in the projects, the Style Guide files (stylesheets, page layouts, etc) aren't getting imported since the Style Guide project path doesn't exist on his machine.

Our solution is to just create a folder structure from the root instead of the Documents (C:\help files\madcap\) and put all our projects in there. If we use the same structure, there's no problems with incorrect reference paths or whatever.

So my question is, what's the best way to move these projects on our local machines?

- Disconnect project from Source Control, move it locally, Reconnect to Source Control
- Disconnect project from Source Control, download it from Source Control in the new location
- Just move projects without disconnecting

Since that Import file has the username path, I'm assuming we'll have to update that link in each moved project regardless of which method we use. I just want to know which is the best way to move stuff locally so it doesn't screw up Source Control and such.

Thanks ...
Software Documentation Specialist (but really, Tech Writer)
Robotman
Sr. Propeller Head
Posts: 185
Joined: Sat Mar 04, 2006 3:05 am
Location: Melbourne, Australia
Contact:

Re: Source control (TFS) and moving project's local location

Post by Robotman »

I would tend to go for option 2 (although we use SVN rather than TFS). You need to ensure all files are checked in beforehand so all files are in the repository.

In terms of your GPL project, though, I'd be inclined to store that on a networked drive rather than on your C:\. Although if your second tech writer gets access to your C:\ and if that location is backed up correctly then this will solve your problem. :)

And, yes, you'll need to update your GPL import file details.
\m/ Gary \m/
Flare 2020 / Windows 10 64-Bit
Screaming Symphony
jsandora
Propeller Head
Posts: 94
Joined: Thu Jun 23, 2011 5:56 am
Location: Boston, MA

Re: Source control (TFS) and moving project's local location

Post by jsandora »

Well, we successfully moved our project files locally, but have introduced another issue: adding files during check-ins with Flare.

Whenever we perform a check-in on a project, we get an error stating files cannot be added to source control. We've resorted to manually adding new files (topics, images, snippets, etc) via Visual Studio as a workaround, but that has quickly become annoying and cumbersome.

For reference, here's what we did:
  • In Visual Studio, removed mappings for Flare projects (old locations that lived behind our individual Users folder on our local machines)
    • This automatically removed the all local files for projects
  • In Visual Studio, added mapping for new location where we wanted to move project files (same path that currently exists in source control - C:/tfs/Help/etc etc etc)
    • This automatically downloaded all files in this new directory, which included project files
When we opened the local version of these projects, several of them indicated they were NOT bound to source control (under Project Properties). When we tried to bind them, kept getting an error saying the files already exist locally or something along those lines.

I eventually manually updated the main project files (.flprj) using a text editor to add these Source Control portions:

Code: Select all

<CatapultProject Version="1" xml:lang="en-us" 
SourceControlBound="true" 
MasterToc="/Project/TOCs/TOC_HTML5_NEW.fltoc" 
IncludePattern="SG*.*" 
AutoExcludeNonTaggedFiles="false" 
IncludeLinkedFiles="false" 
DeleteStale="true" 
AutoSync="true" 
LastImport="2015-02-24T08:36:39.0321616-05:00" 
SourceControlDatabase="http://tfsprod.hq.local:8080/tfs/DefaultCollection" 
SourceControlProviderType="Microsoft Team Foundation Server" 
ProjectGuid="c35326d4-be93-4735-9f05-cf06c956da37" 
SourceControlDatabaseRoot="$/Help/Main/src/WorkingFiles/NetLearning/MyNetLearning/">
This got the projects linked up to source control. But we're still unable to add files via check-in using Flare.

I thought it may be a permissions issue with TFS, but that doesn't seem to be the problem since the files didn't move in source control - only locally.

Any suggestions are welcome, we're stumped!
Software Documentation Specialist (but really, Tech Writer)
NorthEast
Master Propellus Maximus
Posts: 6359
Joined: Mon Mar 05, 2007 8:33 am

Re: Source control (TFS) and moving project's local location

Post by NorthEast »

We have projects in TFS that use imports, and had a similar problem with the import file path name.

To get round the problem, we did this:

(1) Get the projects from TFS, and make sure that they're in the same parent 'projects' folder;
e.g. the parent is C:\Users\bob\Documents\projects\, so your projects might be
C:\Users\bob\Documents\projects\StyleGuide\StyleGuide.flprj and
C:\Users\bob\Documents\projects\AnotherProject\AnotherProject.flprj

(2) Set up a drive mapping for the parent 'projects' folder; e.g. set drive 'P:' to C:\Users\bob\Documents\projects\
I use the prompt 'subst' command for this:

Code: Select all

subst P: "C:\Users\bob\Documents\projects\" 
Everyone else maps a drive using the same drive letter 'P' to their own projects folder, e.g. C:\Users\jane\Documents\projects\ or F:\MyWork\projects\
We create a batch (*.bat) file with the 'subst' script above, and run it on Windows startup so it's always ready.


(3) When you set up an import, select the project from drive 'P', e.g. so the path is something like P:\StyleGuide\StyleGuide.flprj

This means that the path to the project (from P:) is the same on everyone's PC.



Mind, you have to be careful when using project imports and source control.

When you re-import, make sure that you update all files that are different, including those where it says 'local is newer' (marked red).
The import works by comparing the file date (not the version of the file), which is the date you got the file locally from source control, not the file's date (i.e. version) in source control.

Therefore, just re-importing 'source is newer' files (green) is not a reliable way to get the latest versions of files, and you also need to re-import all files where 'local is newer' (red).

Due to this problem, we have to re-import and change hundreds of extra files, since everyone's file dates (when they get files from source control) are different on their own PCs.
Wendy_Pod
Propeller Head
Posts: 21
Joined: Thu Jun 15, 2017 2:50 pm

Re: Source control (TFS) and moving project's local location

Post by Wendy_Pod »

Dave Lee wrote:
(2) Set up a drive mapping for the parent 'projects' folder; e.g. set drive 'P:' to C:\Users\bob\Documents\projects\
I use the prompt 'subst' command for this:

Code: Select all

subst P: "C:\Users\bob\Documents\projects\" 
Hey Dave,

I know this is an old post, but wanted to ask you about the behaviour of your virtual P:\ drives and the recycle bin. It seems that on Windows Vista and newer, virtual drives are handled like network drives and deletions will not use the recycle bin.

Have you had any issues with content not appearing in the recycle bin? I'm thinking when using Analyzer tools, which are designed to use the recycle bin for 'undo' type actions.

Thanks,
Wendy
Post Reply