newbie Source Control question

[Greg]

The Source Control pdf reads:

"If you are working on a multi-author team, each writer on the team needs to have a local copy of the Flare project
and will be responsible for checking in and checking out files as necessary."

I know that sounds straightforward enough but is that really true? Currently, all of our Flare projects are stored on servers that are backed up every night. Local machines are not.

Is it really impossible to utilize the Source Control feature unless every writer has every project they work on written locally to their machine first?

Thanks,

Greg

[Paul Griffiths]

I have never heard of a source control product that didn't use a local working copy, although I suppose it's possible. It doesn't matter that your local machines aren't backed up every night, as long as every author remembers to commit their changes to the server at the end of the day (ideally, more frequently than that).

[RamonS]

Paul is right, the project files are worked on locally and only on command are sent up to the source control server. Think of a source control system as a big file server that has version control and allows for working on the same file at the same time assuming the system supports merging changes. The local copies are necessary to cut down on network traffic and improve overall performance (unlike cloud services).

[svt-user]

It is not really a full local copy, more of a "ghost instance" of the Flare project. It is only when a writer checks out a topic file (or saves a modified local copy) that the individual local topic file becomes a full local working copy. The rest of the project is still a "ghost". (If you try to manually change project files outside of Flare, you'll probably find that the file permissions prevent you from editing or deleting the file.)

In Multiauthored projects, Two or more writers might simultaneously make changes to the same topic - so there can be multiple local working instances of a topic file. On commit, only the differences (deltas) between local instances and the actual project file (in the SVN repository, on the server) are merged in to the base file. However, If you happen to get two simultaneous commits that affect the same lines in the same file, then you might get merge contention that must be resolved through manual merges.

In practice, it's better to maintain a low level of topic granularity (smaller bits of content) in a hierarchical folder structure. That way, the chance of simultaneous edits and manual merges is low.

[RamonS]

And assign specific areas of work to the multiple authors. Sure, there are things that have a wider impact, but everyone editing everything will lead to problems. The nice thing of a source control system is that you can go back to a stable place even after a botched merge...and I have to find a source control system that does merges reliably well.