1. Software development IS communication. To make it otherwise is to make
it harder than it should be.
Seems you either wait to ask for a file or you wait to see when the file is
unlocked. Or you change how you work as a team such that asking is usually
answered right away.
2. Don't rewrite, separate and organize. For example: One function per
file. Or five per file or something like that. This will increase the
granularity of the files and decrease the chance that two people will want
the same file at the same time. Not knowing your code, even this simple
rule could be a bit difficult to do. It's still easier than being locked
out of files when you need them or wiping out the other developers
modifications.
3. Poor craftsmanship has a high cost, yes.
All my experience with VSS tallies up to calling it barely usable. It did
file locking by default and has thus trained many developers that locking
is a necessity. CVS was invented years before VSS and it has strong
merging capability. The "C" stands for concurrent, after all!
IMO file locking is a brute force bandage hiding other incorrect practices
that developers don't think hurts the work and product.
Sorry to steer the conversation away from your question. I don't know what
alternatives to Git do file locking since I don't use that feature, even if
it is available.
Alan
On Wed, Mar 7, 2012 at 6:19 PM, keith smith <
klsmith2020@yahoo.com> wrote:
>
> 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>
>
> Subject: Re: GIT and Github - howto.
> To: "Main PLUG discussion list" <plug-discuss@lists.plug.phoenix.az.us>
> Date: Wednesday, March 7, 2012, 5:31 PM
>
>
> The 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
>
> On Mar 7, 2012, at 5:22 PM, keith smith <klsmith2020@yahoo.com<http://mc/compose?to=klsmith2020@yahoo.com>>
> wrote:
>
>
> 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<http://mc/compose?to=jmcphe@gmail.com>
> >* wrote:
>
>
> From: James Mcphee <jmcphe@gmail.com<http://mc/compose?to=jmcphe@gmail.com>
> >
> Subject: Re: GIT and Github - howto.
> To: "Main PLUG discussion list" <plug-discuss@lists.plug.phoenix.az.us<http://mc/compose?to=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-----
>
> ---------------------------------------------------
> 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
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us<http://mc/compose?to=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
>
>
> -----Inline Attachment Follows-----
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us<http://mc/compose?to=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
>
>
> ---------------------------------------------------
> 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
>
---------------------------------------------------
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
(text/plain)