<div dir="auto"><div>Roland, Nicole and list,<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 15, 2020, 08:08 Roland Berger <<a href="mailto:roland.berger@steinerpartner.com">roland.berger@steinerpartner.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div>
    Hi Nicole<br>
    <br>
    An other idea is to use a version control system where you need to
    check-in and check-out the projects. <a href="https://www.perforce.com/" target="_blank" rel="noreferrer">https://www.perforce.com/</a> has
    this kind of feature.<br>
    But this would add another system to your infrastructure and as such
    it is not a light weight solution for you problem. <br>
    <br>
    Best Roland<br>
    <br>
    <div>On 12/15/20 4:49 PM, Nicole Stoffels
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="auto">
        <div dir="auto"><br>
        </div>
        <div dir="auto">Dear QGIS-users,</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">we are several people, sometimes working on the
          same QGIS-project without knowing it. Unfortunately you never
          get a warning that anyone else is currently working on the
          project, when opening the project file. That is why I would
          like to generate a warning, that person xy is working on the
          project.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">I did some research and came to this page, where
          the suggestion is to write a macro, which looks for lock files
          in the project directory:</div>
        <div dir="auto"><a href="https://gis.stackexchange.com/questions/186309/open-qgis-project-files-in-exclusive-mode-alert-if-project-file-already-in-use" target="_blank" rel="noreferrer">https://gis.stackexchange.com/questions/186309/open-qgis-project-files-in-exclusive-mode-alert-if-project-file-already-in-use</a></div>
        <div dir="auto"><br>
        </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Moreover this was already an issue 4 years ago:
          <a href="https://issues.qgis.org/issues/14717" target="_blank" rel="noreferrer">https://issues.qgis.org/issues/14717</a></div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Seems that it has not been fixed yet?</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Unfortunately my QGIS does not even write a lock
          file in the working directory. And I always get the warning
          that macros are currently not working.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Do you have any other ideas how to solve this
          problem? Or any idea, how to get QGIS to write this lock file?</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto"></div></div></blockquote></div></blockquote></div></div><div dir="auto">If you have several people working on the same project file, Roland's suggestion is interesting and could have merit, depending on why you are all working on the same project.</div><div dir="auto"><br></div><div dir="auto">Remember that with version control the steps are generally:</div><div dir="auto"><br></div><div dir="auto">- each user checks out a copy of the shared file from a central server into a private working directory</div><div dir="auto">- each user commits their changes locally when they are satisfied</div><div dir="auto">- each user pushes the changes back to the central server, which may require managing conflicts - but here users are aware of the task and dealing with it, rather than trying to get some piece of code working.</div><div dir="auto"><br></div><div dir="auto">What you probably need to do in this case is decide whether you can work on separate private copies, periodically merging your changes - a clue would be that you tend to work on separate "parts" of the project, so that your changes would tend to be independent and therefore easily merged.</div><div dir="auto"><br></div><div dir="auto">Going back to the lock file business, lock files on network file systems aren't generally guaranteed to be atomic as far as I know so that might not be the most reliable approach.</div></div>