Re: GIT and Github - howto.
On Thu Mar 08 12, Tom Haws wrote: Keith, Git is magic and it will make all your troubles go away. Really. I am speaking from real world before-and-after experience with two clients/projects in the past two years. Call me and we can discuss it 480-201-5476. And you can also start by watching this essential Youtube talk by Linus Torvalds http://www.youtube.com/watch?v=4XpnKHJAok8 . Another video that is good at explaining git and workflows involving git is Scott Chacon's 'Getting Git' presentation. http://vimeo.com/14629850 --- 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
Re: GIT and Github - howto.
please what troubles will disapear? On Thu, Mar 22, 2012 at 2:13 AM, Gerard Snitselaar d...@snitselaar.orgwrote: On Thu Mar 08 12, Tom Haws wrote: Keith, Git is magic and it will make all your troubles go away. Really. I am speaking from real world before-and-after experience with two clients/projects in the past two years. Call me and we can discuss it 480-201-5476. And you can also start by watching this essential Youtube talk by Linus Torvalds http://www.youtube.com/watch?v=4XpnKHJAok8 . Another video that is good at explaining git and workflows involving git is Scott Chacon's 'Getting Git' presentation. http://vimeo.com/14629850 --- 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 -- :-)~MIKE~(-: --- 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
Re: GIT and Github - howto.
Specifically the trouble you have being able to collaborate with others because you feel you have to wait on others to finish their edits before you can work on the code base, that trouble will go away partly because Git is super smart and partly because Git has something no other package (even Mercurial/Hg) has: cheap (easy) branching. The trouble you have putting somebody's work together with your own will go away because Git integrates very well with diff tools like meld to help you even do manual merges with a minimum of confusion and worry. The trouble you have multi-tasking with your code base will go away because you will have multiple branches going on at the same time with Git, and you will be creating and deleting branches all the time. I just got through programming a feature in the production tree, then with git difftool was able to port it to a development branch relatively easily even when some file names had changed or been deprecated. This was the messiest thing I had done, and I was blessing the name of Git all the way. Tom On Thu, Mar 22, 2012 at 2:18 AM, Michael Havens bmi...@gmail.com wrote: please what troubles will disapear? On Thu, Mar 22, 2012 at 2:13 AM, Gerard Snitselaar d...@snitselaar.orgwrote: On Thu Mar 08 12, Tom Haws wrote: Keith, Git is magic and it will make all your troubles go away. Really. I am speaking from real world before-and-after experience with two clients/projects in the past two years. Call me and we can discuss it 480-201-5476. And you can also start by watching this essential Youtube talk by Linus Torvalds http://www.youtube.com/watch?v=4XpnKHJAok8 . Another video that is good at explaining git and workflows involving git is Scott Chacon's 'Getting Git' presentation. http://vimeo.com/14629850 --- 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 -- :-)~MIKE~(-: --- 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
Re: GIT and Github - howto.
funny guy! On Thu, Mar 22, 2012 at 7:10 AM, Tom Haws tom.h...@gmail.com wrote: and I was blessing the name of Git all the way. --- 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
Re: GIT and Github - howto.
Oops. Pun not noted previously. No wonder that rolled off the tongue so well. :-D -- To forgive is the highest, most beautiful form of love. In return, you will receive untold peace and happiness. - Dr. Robert Muller On Thu, Mar 22, 2012 at 10:11 AM, Michael Havens bmi...@gmail.com wrote: funny guy! On Thu, Mar 22, 2012 at 7:10 AM, Tom Haws tom.h...@gmail.com wrote: and I was blessing the name of Git all the way. --- 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
Re: GIT and Github - howto.
Keith, Git is magic and it will make all your troubles go away. Really. I am speaking from real world before-and-after experience with two clients/projects in the past two years. Call me and we can discuss it 480-201-5476. And you can also start by watching this essential Youtube talk by Linus Torvalds http://www.youtube.com/watch?v=4XpnKHJAok8 . But for the benefit of the list, here's the scoop on Git. 1. Yes, you can work on the same file simultaneously. We are doing it all the time. And the magic only begins there. 2. Yes, some coordination helps, but Git's (or Mercurial's) magic helps unbelievably. 3. The occasional manual merges referred to, in real life, usually stem from either a) gross miscommunication or b) clumsiness (inevitable) with Git. It's okay, Git's (or Mercurial's) there to help you. 4. Manual merges are SUPER easier thanks to Git. As I've hinted (and Linus Torvalds admits) Mercurial/Hg is a worthy alternative to Git. SVN/CVS are not. Maybe if I get some free time I can help you out. I'm still in Gilbert. Bottom line: Git IS magic, and it WILL turn your nightmares into rainbows. Tom -- To forgive is the highest, most beautiful form of love. In return, you will receive untold peace and happiness. - Dr. Robert Muller On Wed, Mar 7, 2012 at 6:42 PM, Alan Dayley aday...@gmail.com wrote: 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 klsmith2...@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 aday...@gmail.com* wrote: From: Alan Dayley aday...@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 klsmith2...@yahoo.comhttp://mc/compose?to=klsmith2...@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
GIT and Github - howto.
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
Re: GIT and Github - howto.
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 klsmith2...@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 jmc...@gmail.com --- 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
Re: GIT and Github - howto.
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 jmc...@gmail.com wrote: From: James Mcphee jmc...@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 klsmith2...@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 jmc...@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 To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
Re: GIT and Github - howto.
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 klsmith2...@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 jmc...@gmail.com* wrote: From: James Mcphee jmc...@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 klsmith2...@yahoo.com/mc/compose?to=klsmith2...@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/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 -- James McPhee jmc...@gmail.com /mc/compose?to=jmc...@gmail.com -Inline Attachment Follows- --- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us/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
Re: GIT and Github - howto.
From: keith smith klsmith2...@yahoo.com 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. Lock-modify-check in-unlock is the old way, dude. You can *do* that using SVN, but you're discouraged from doing so repeatedly in the documentation. Apparently, now you're supposed to grab everything, modify things, then merge, handling conflicts/breakage via your brain. This makes it easier to modify parts of a huge project. (It can create problems for small projects with few developers, but who cares about those projects, anyway?) Note that these problems were also present in older things like CVS, but CVS is very infra dig now because it's so annoying to move/rename things in CVS. If you *need* exclusive locking, git is the wrong source-code versioning system to use. But as Alan said, you probably don't need exclusive locking as much as you think. -- Matt G / Dances With Crows The Crow202 Blog: http://crow202.org/wordpress/ There is no Darkness in Eternity/But only Light too dim for us to see --- 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
Re: GIT and Github - howto.
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 aday...@gmail.com wrote: From: Alan Dayley aday...@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 klsmith2...@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 jmc...@gmail.com wrote: From: James Mcphee jmc...@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 klsmith2...@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 jmc...@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 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 To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss--- PLUG-discuss
Re: GIT and Github - howto.
More like an old dude trying to learn a new trick. Thank you for sharing your knowledge and guiding me down the right path. It is much appreciated. Keith Smith --- On Wed, 3/7/12, Matt Graham danceswithcr...@usa.net wrote: From: Matt Graham danceswithcr...@usa.net Subject: Re: GIT and Github - howto. To: Main PLUG discussion list plug-discuss@lists.plug.phoenix.az.us Date: Wednesday, March 7, 2012, 5:43 PM From: keith smith klsmith2...@yahoo.com 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. Lock-modify-check in-unlock is the old way, dude. You can *do* that using SVN, but you're discouraged from doing so repeatedly in the documentation. Apparently, now you're supposed to grab everything, modify things, then merge, handling conflicts/breakage via your brain. This makes it easier to modify parts of a huge project. (It can create problems for small projects with few developers, but who cares about those projects, anyway?) Note that these problems were also present in older things like CVS, but CVS is very infra dig now because it's so annoying to move/rename things in CVS. If you *need* exclusive locking, git is the wrong source-code versioning system to use. But as Alan said, you probably don't need exclusive locking as much as you think. -- Matt G / Dances With Crows The Crow202 Blog: http://crow202.org/wordpress/ There is no Darkness in Eternity/But only Light too dim for us to see --- 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
Re: GIT and Github - howto.
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 klsmith2...@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 aday...@gmail.com* wrote: From: Alan Dayley aday...@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 klsmith2...@yahoo.comhttp://mc/compose?to=klsmith2...@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 jmc...@gmail.comhttp://mc/compose?to=jmc...@gmail.com * wrote: From: James Mcphee jmc...@gmail.comhttp://mc/compose?to=jmc...@gmail.com Subject: Re: GIT and Github - howto. To: Main PLUG discussion list plug-discuss@lists.plug.phoenix.az.ushttp://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 klsmith2...@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
