Jump to content

php editor lock files preventing multi person access to the same file?


Recommended Posts

Yet another php editor thread...

 

Does anyone know of an editor which will place 'lock' files into the directory of the file being opened which prevents anyone else opening the same file?

 

I have up to 3 persons working on the same group of files at the same time and management of it can be a bit of a nightmare at the moment as we have no way of telling if a file is open by anyone else without shouting over 'anyone working on xfile.php?'. We have easyPHP using the same root folder over a network, we just need an editor or some other trick which places a temporary lock file in the dir in the same way openOffice does (and in fact most other programs from adobe to solidworks). Has anyone else stumbled upon this problem and found a solution?

 

I understand there can be systems set up to project manage situations like this but they can be a little overkill for what I think i need, a simple lock file will suffice here i think as we are all in the one office.

 

(notepad++ and crimson editor don't seem to prevent this.)

 

Thanks, John

 

You seriously shouldn't have multiple developers working on the exact same set of files. Use a version control system, this is one of there many benefits.

 

Git is an awesome tool, and is only as complicated as it needs to be. Simple tasks are just that, simple. More complex tasks obviously become more complex though.

 

I don't even work alone without version control these days, it really is a must have tool for any real developer.

 

Git is awesome! However, I can't seem to get it to solve my original problem: I want to be able to simply block any other developer working on the project from opening in an editable way the same file i am working on.

 

Got Git up and running today, pretty awesome tool.. pretty straight forward and to step backward and forward through changes to files... etc.

Had a look at the '.git;.... how does it work? Does it simply store the changes to the file and not duplicate the file it self as the .git dir never increases by the actual file that it 'backed up'? Pretty clever.

 

What we got working:

1 - We got Git installed on 2 computers both had access to the local network both running windows. We then installed a GUI interface for git, SmartGit on both.

2 - Initialized a .git into the root of a test project on the network on computer 1

3 - Opened the same working tree on computer2.

We now had both SmartGits working working on the same files. When computer1 made changes to fileA, computer2 could see these changes on their smartgit and see all commit comments...etc.

 

What we could not get to happen:

Could not get the SmartGit (:D) to tell the other computer that fileX was already open which is essential to us. We have a very small team sometimes working on the same site at the same time, as a result it is important to us that when developerA works on fileX developerB is made aware thus cannot open for editting the same file. If there is an editor out there that places in the dir a simple locking file then I would have the very best of both worlds, a versioning system and the ability to prevent multi editable access to the one file.

 

(I really hope i have just missed a setting somewhere that enables the prevention of multiaccess to the same file :) )

You should not have developers working on the same repositories. Each dev should there own repository, and you will likely want a central repository that they push there changes to. You should look into gitolite to make the central repository maintenance easier, or use a service such as github.com 

freelance84, you need to change the way you're doing things.  First you setup a git repository with your project, what you've been using as your master files that both developers have been editing at the same time thus far.  From now on your developers will no longer edit those 'master' files directly, instead they will clone (create a local copy of) the master repository, edit those local files and when they are done with their edit will commit their change to the local repository and to update the master repository will push the edit to the master repository.  To make sure the developers have the most up to date version of the master repository and without grabbing the whole repository with clone again they will issue a pull against the master repository.

 

I'm sure the git documentation does a better job explaining.

 

Disclaimer, I'm still a subversion user so I may not be totally accurate or sane. :P

 

Ok, i get how to use Git. I love that you can compare the changes between files an update accordingly with Git, it is pretty flippin awesome!

 

About half a year ago, i set up 'control system' which essentially flagged files as locked and not locked c/w job lists for each file through MySQL which in turn prevented two people working on the same file at the same time. We were using the repository on the server as the master collection and each held a cloned copy on our local machines (we did not use that terminology mind). The need for this was simple, we (2 of us) were building a few different sites together at the same time, there was a general list of jobs to complete for each site and the locking system simply meant we did not waste time doing the same job at the same time. The system was created as we were to be working for a duration of time in 2 different countries.

 

The system worked great, no files were ever worked on at the same time as long as each user only opened the file having gone through the online php control system. One problem with this was there was no notification system set up to tell other devs on the project if a file had been locked and then unlocked, meaning no-one knew whether or not to download the latest file. In response to this we simply agreed that the server should at all times hold the complete working files, and any jobs we were to do should be done by first downloading a copy of the master and developing on our local machines. Kind of a tedious method, simple, but it worked for us.

 

Git is insane in its ability to see past versions...etc, however i still cannot see a method that allows anyone else to see when a file has been opened for development. For a project with lots of devs I can see might be all that important, but for us it is.

Example scenario:

Dev1 starts work on jobNo 17/18/19 for pageX

Dev2 now has no idea what Dev1 is working on without asking which can result in both devs working on the exact same problem at the same time, which is a complete waste of time.

 

The problem only gets more complex with a 3rd person. Thing is we have found that we work really strong as a team and when we manage who works on which file at what time (regardless of whether there is a central repos. on the server or cloned ones on local machines) which saves buckets of time.

 

If there was a system like Git which simply flagged to other users when fileX had even been opened this would solve this problem (even if the devs have their own clones or the central set). There must be something to enable this.

 

 

This is where project management comes into play. Your developers should be assigned tasks, bug fixes, new developments, etc. Obviously if 2 developers are assigned 1 bug, they should be communicating back and forth on what is going on. Otherwise, typically you shouldn't run into the problem of 2 developers editing the same, in the same place. And in the case that they are editing the same file - that's what merge is for! :)

Yea, but then there's little point in two equally skilled people doing a the same task as the outcome will usually be pretty similar, thus using merge there is completely pointless. With regards to management, I am just trying to get a system which enables this area of management to be a little easier and possibly somewhat more automated thus increasing the amount of time writing the stuff we're meant to be writing :)

 

OK, so the answer really is no: There is no syntax highlighting editor out there at the moment which will place a lock on a file to prevent others from opening and editing said file in the same fashion that open office does.

 

 

(however, thorpe, thanks a bundle for introducing me to git. It is cool, can't believe i have gone so long without even knowing about it!)

two equally skilled people doing a the same task as the outcome will usually be pretty similar

Which is why I'm saying bring on the project management. Unless you're letting your team run around fixing and working on whatever they please like monkeys in a zoo pen, this shouldn't be occurring :)

Project management like redmine, trac or jira would allow a lead developer to create a workflow where tickets/issues/tasks are assigned to developers or allow the developers to tag an issue as being worked on by them thus removing the concurrent duplicate work.

Yea, but then there's little point in two equally skilled people doing a the same task as the outcome will usually be pretty similar, thus using merge there is completely pointless.

 

It's been said before but I just wanted to reiterate. For this, you need some form of project management. An issue tracker allows worked to be documented. People add a ticket for work needing to be done, devs then assign it to themselves (or a lead might assign tickets for you), this way no one else will be working on a ticket that isn't assigned to them.

 

How do you think projects with multiple devs work? People don't just go around willy nilly editing files.

 

king phil, mr hippy and thrope, cheers, it might have been said before but i didnt realise there was project management software available for web design.

 

Nice thread tho, i know now about git and project management programs :)

 

Muchos Gracias!!

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.