If compilable code is rebuilt whilst being mirrored?

[Guest]

Can this cause a problem? I am a Vice Versa user via a corporate license. Its task is to mirror changes on my local hard disk to a network location. From my PoV it does this pretty slowly (partly because of network target location, partly because it's attending to umpty-diddly others "at the same time"). However, I haven't concerned myself overly with the way it does things, because I have no control over it. Until now.

Yesterday I was using my compiler and debugger to make some changes to old code that has worked perfectly for a long time. I was rebuilding pretty frequently, and I started to get some really worrying errors that were completely inexplicable, not least because after an hour or so (and a cold reboot, and some pointless rearrangement of code), they went away again. I am wondering if Vice Versa might have been implicated? Here's the approximate hypothetical scenario:

Suppose an exe is rebuilt, thus renewing the exe file and its concomitant object code. That triggers a mirroring process. Suppose that process is not complete before another rebuild takes place, triggering another mirroring process, and possibly so on. Without knowing the dirty detail of how Vice Versa does what it does, it seems to me to be possible that the mirrored version of the object code could end up "hybrid" - a mixture of the two rebuilds - and this mixed version would then be mirrored back (because ultimately, the files in the two locations have to end up the same). The next rebuild would then be based on a mixture of object code and would produce a corrupt exe, exacerbating the situation.

Is something like this a remotely plausible situation?

Andy

[TGRMN Software]

Hello Andy

I do not know how you setup ViceVersa, but usually you end up with the target being a perfect mirror of the source. If you compare source and target it will show that all source and target files are identical.
What may have happened is that you used the target while it was not (yet) a perfect mirror of the source and hence the errors.

thanks
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com

[Guest]

I don't set it up - it's set up for me - so I can't comment definitively on that (although I have been told that it is set up so that it is possible to make changes to either source or target, and the mirroring will be bidirectional). What I can comment on is that I only ever make use of the source, never the target - the target is there purely for backup. What I am fretting about is the possibility that in trying to mirror a file that is "in a state of flux", the target will end up different to any of the well-defined states that the source is temporarily in, and that precisely because target and source must always end up the same, the source will end up being updated again when it should not. If you see what I mean.

I was looking at the FAQs, specifically about file conflicts. If something like I am describing had been going on, presumably this ought to register as file conflict, and therefore ought to show up in a log file (if I'm using Pro rather than Plus; I need to find that out). I'm not clear what either version actually does in the event of a file conflict; does it "do nothing"?

Andy

[TGRMN Software]

Hi, if a file is changed in both source and target, in between synchronizations, the file is marked as a conflict and it is not copied in either sides. In that case, you could have a different file in source and target, until you manually resolve the file conflict.
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com