Thanks Alan,
1. Developers are not communicating enough. - I was hoping to reduce the need to verify each time I need a file or a group of files. This can be rather time consuming especially when we work when we want and may have a last minute task to fix or modify something that takes minutes.
2. The source file organization needs improvement (files too big, unlike functions/methods in the same file, etc.) - There is a little of this going on. Sometimes you get what you get and you do not have the luxury to rewrite massive amounts of code.
3. The architecture of the product, and therefore the code, is suboptimal. - From my experience, especially in the PHP world this is the nature of almost all the code I have seen.
In the end it looks like we will just have to communicate more.
17 years ago I worked with a company that used Visual Source Safe. There was 4 of us and a lead. On a number of occasions it it saved us from stepping on someone else's modifications. I'm not sure how you can track the work of 4 people working all day on small modifications to an existing system without spending a lot of time coordinating.
------------------------
Keith Smith
--- On Wed, 3/7/12, Alan Dayley <adayley@gmail.com> wrote:
From: Alan Dayley <adayley@gmail.com>Date: Wednesday, March 7, 2012, 5:31 PMThe need for source file locking is often an indicator of a problem. Three likely ones:
1. Developers are not communicating enough.
2. The source file organization needs improvement (files too big, unlike functions/methods in the same file, etc.)
3. The architecture of the product, and therefore the code, is suboptimal.
Fix the reason file locking is needed instead of diminishing the ability to get work done.
Alan
Thanks James. What is everyone else doing. I'm sure others have had the problem of needing to "check out" code so others cannot modify the file.
------------------------
Keith Smith
--- On Wed, 3/7/12, James Mcphee <jmcphe@gmail.com> wrote:
From: James Mcphee <jmcphe@gmail.com>
Subject: Re: GIT and Github - howto.
To: "Main PLUG discussion list" <plug-discuss@lists.plug.phoenix.az.us>
Date: Wednesday, March 7, 2012, 4:51 PM
Git doesn't really allow file locking. You'd have to have some good communication to prevent working on the same file. Or... You can use the merge process. If the other person updates a file, pushes to the repo, and you try to pull it in after you've updated same file, you will be told you need to merge. That can get messy, but git has no built-in way to lock a file.
On Wed, Mar 7, 2012 at 4:36 PM, keith smith <klsmith2020@yahoo.com> wrote:
Hi,
I have GIT installed on my server and I have Github. I understand the versioning part. The concept I am having trouble grasping is how I can use it a collaboration tool.
It is just me and another programmer. We both have a local dev environment. We work out of our homes and we live a fair distance apart - about a 1.5 hour drive.
We have a server in a data center that contains both our test server and our production server.
To this point we have worked on separate parts of this online app so we have not had any occasion to step on what they other guy is doing.
The two of us will be taking on a project that will require us to work within the same code set.
What we need to achieve is a way to checkout a PHP file work on it and then check it back in. While the file
is checked no one else should be able to use it.
I've been reading about GIT, however it is not clear if I can use it this way.
Your guidance is much appreciated.
------------------------
Keith Smith |
---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
--
James McPhee
jmcphe@gmail.com
-----Inline Attachment Follows-----
|
-----Inline Attachment Follows-----
|