Totally new to Source Control

[The_docman]

Hi
I am totally new to Source Control and quite new to Flare.

I need a source control system for the Flare projects I am producing and I am not sure which ones to take seriously.

I'm looking for relatively easy setup plus reliability and transparency with Flare (and hopefully low cost).

Any ideas?
Thanks

[Paulie]

SVN and Git are both free/cheap. Personally, I have used SVN for around ten years, and quite frankly, I can't imagine working without it.

Here's a tutorial/brief overview of SVN:
http://www.mind.ilstu.edu/research/comp ... ntutorial/

One thing to note: I don't use Flare's SVN integration. I prefer to use TortoiseSVN.

[Nita Beck]

I've used SVN for about three years and Git for less than a year. I much prefer Git, and I believe that Flare's integration with Git is better than it is with SVN. In fact, I've had lots of issues with Flare 11 and SVN but no issues at all with Flare 11 and Git.

I'll elaborate a bit.

With SVN, there is one repository that holds the Flare project, typically on a network drive somewhere. You have a copy of the Flare project on your computer, and all changes that you make to that copy have to individually be checked out of and into that one remote repository. In my experience, Flare 11's performance in making all those back-and-forth communications with the remote repo is terribly laggy and I, for one, experience a real hit to my productivity.

With Git, you have a copy of the project on your computer, plus a local repo on the computer so that all the changes you make have to interact with that local repo and there's no lag whatsoever. There is also (typically) a remote repo, and the individual authors can push their local repo changes to the remote repo in one operation or can pull changes from the remote repo to their local repo in one operation, so again, there's very little lag. In my experience, using Flare with Git has been a breeze.

There's an issue to be concerned with, however. Ask your repo admin what protocol you must use when communicating with the repo, either SVN or Git. Currently, Flare's Git implementation does not support SSH protocol, which makes Git unusable for some users, including me for one of my clients who insists on SSH. For that one client, I'm sticking with SVN, which does support SSH protocol.

If you work in/support a software development department, find out what source control the devs are using and see if you can use the same... It'll make life easier for you as a new source control user if you've got others who can lead the way.

[MattyQ]

If your organization is already using Visual Studio/Team Foundation Server, Microsoft provides a free standalone application called Team Explorer that you can use with TFS for source/version control, too. We've been utilizing Team Explorer and TFS with some in-application performance hits, but it's fairly snappy for most operations.

[The_docman]

Thanks for the responses.

[NorthEast]

If your organization is already using Visual Studio/Team Foundation Server, Microsoft provides a free standalone application called Team Explorer that you can use with TFS for source/version control, too. We've been utilizing Team Explorer and TFS with some in-application performance hits, but it's fairly snappy for most operations.

Out of curiosity, why do you use Team Explorer, when Flare already has built-in integration for TFS?

We use TFS, and I usually find it's a lot better to let Flare handle everything with TFS.
I sometimes access TFS source control using Visual Studio/Team Explorer, but just in special cases.

[MattyQ]

...why do you use Team Explorer, when Flare already has built-in integration for TFS?

Hey, Dave,

Yeah, good question. Initially we were using Flare mostly, but we started running into a few different scenarios/issues that inclined us to all utilize Team Explorer in addition to the in-application TFS interface.

We still do getting the latest version of files, check-ins, and check-outs primarily through the Flare interface.

One of the primary issues is branching and merging. A body of the documentation is branched with each version of the software, and in certain cases we're merging changes to topics from one branch into another. Flare doesn't provide any support for handling merging across branches.

Another issue appears to be a bug with the Merge Changes interface in Flare (11 specifically?). When the occasional problem arises, if there are several conflicts in a project, the Merge tool fails when it tries to iterate through each topic. So, you can complete a merge in one topic, but when it tries to iterate to the second topic the dialog box stops working and you have to close it and reinitiate the whole check-in procedure. At that point, it moves to topic 2 (since you've already fixed topic 1). Again, you complete the merge, but the tool fails when it tries to move on to topic 3. To note, also, we found that the issues you resolved in Flare weren't consistent in TFS. It seems like it overlooks changes in certain cases? A bug, again, I assume.

Initially, we had writers using the Pending Changes window in Flare, but performance went down substantively while the window was active in Flare. For some writers, the application became totally unresponsive. Additionally, we found that it wasn't accurately reflecting file statuses. Often files were checked out that weren't included in the Pending Changes window (for the working project), and often new files to be added to TFS weren't being reflected. Again, to note, we're doing our check-ins and check-outs via Flare, not via TFS.

We often build using madbuild.exe, and use the Import Before Generating Output option in our import files to keep projects up to date with the latest style changes from a global project. Often, at the end of the process, we'll end up with a thousand or so files checked out to the user who's doing the madbuild procedure (we build several projects in succession). From there, it's easier to check in or undo those changes after the build via Team Explorer, rather than opening each project to check in those files.

Finally, we found regular issues with Flare leaving files sitting in the Pending Changes pane in Team Explorer/Visual Studio (when we were using it). Usually this corresponded to files that also weren't displayed in the Pending Changes window in Flare. This seems to be partly related to deleting files via Flare, though I'm trying to remember the other particular scenarios when this was an issue.

Here's the workflow we're currently using, which seems to mitigate all issues. Let me know if anything sounds off:
1. Open a project in Flare.
2. Get the latest version of all files (Flare dialog).
3. Check out the files you're working in (whether initially, or as you're working on them) via Flare.
4. Make changes and save. Add new files. Delete Files.
5. Check in changes via Flare.
5a. If conflicts, open Team Explorer and resolve each conflict. Complete check-in via Team Explorer.
6. Check Team Explorer for additional Pending Changes.
7. Resolve the remaining Pending Changes (check in or undo).
8. If necessary, merge changes from that branch into another branch.


Definitely appreciate any input you have, Dave, as usual. =)

Thanks!

[NorthEast]

Thanks for the detailed info.
Yeah, that sounds about right, I only use Visual Studio to manage things in TFS as a last resort.
We don't have performance issues, or branch projects (though that might change), so rarely need to sort things out manually.

I just mentioned it because if someone's new to source control, then they want to be using Flare first - and use things like Team Explorer or Visual Studio for troubleshooting or branching/merging.

[MattyQ]

I just mentioned it because if someone's new to source control, then they want to be using Flare first - and use things like Team Explorer or Visual Studio for troubleshooting or branching/merging.

Yeah, good call, and thanks! I mostly wanted to suggest it because we were under the impression that you needed Visual Studio, which is expensive (understated), and wanted to suggest a free-ish (depending on existing licenses) alternative.