Hello, I''m sorry if this is not the right place for this question. Please feel free to point me in the right direction. Also take into consideration that we have never used a version control system so my questions might just be due to lack of knowledge and/or understanding as of how to use the VCS. Is there a version control system (be it git, TortoiseSVN, other...) that will be able to take care of the following scenario? Having a ''vanilla'' version of an application we have 3 customers, each with enough changes to their version of the application that no version can be merged back to the vanilla one, hence ending up with 4 versions: the vanilla one plus 3 others, one per customer. We need a VCS that will allow us to make changes to the main ''vanilla'' version and propagate those changes to the other versions and, better yet, to propagate those changes selectively, meaning to only 1, or 2, or the 3 other versions on demand. Thanks in advance. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Apr 10, 3:25 am, pepe <P...-1PhG29ZdMB/g+20BJ0uB2w@public.gmane.org> wrote:> Hello, > > I''m sorry if this is not the right place for this question. Please > feel free to point me in the right direction. > > Also take into consideration that we have never used a version control > system so my questions might just be due to lack of knowledge and/or > understanding as of how to use the VCS. > > Is there a version control system (be it git, TortoiseSVN, other...) > that will be able to take care of the following scenario? > > Having a ''vanilla'' version of an application we have 3 customers, each > with enough changes to their version of the application that no > version can be merged back to the vanilla one, hence ending up with 4 > versions: the vanilla one plus 3 others, one per customer. > > We need a VCS that will allow us to make changes to the main ''vanilla'' > version and propagate those changes to the other versions and, better > yet, to propagate those changes selectively, meaning to only 1, or 2, > or the 3 other versions on demand. >git is pretty smart at merging stuff between branches (way more so than svn which would end up being a bit of a nightmare in this case). I''d bear in mind that even with git helping you you are increasing your maintenance burden significantly - everytime you add a new feature or fix a bug you need to be taking into account the 4 variations of the app and how the differences between them might interact with the change you''re making. If you can manage it it may make your life easier to keep one codebase but make each deployment of your app more configurable. Fred -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 10 April 2010 03:25, pepe <Pepe-gUAqH5+0sKL6V6G2DxALlg@public.gmane.org> wrote:> Also take into consideration that we have never used a version control > system so my questions might just be due to lack of knowledge and/or > understanding as of how to use the VCS.Well, distributed version control is going to be your friend here, but you are going from a standing start to pretty much the most complicated use of it. Personally, I''m a Mercurial fan, but Git is very similar. Either way, both tools allow developers to maintain their own clones of a central repository, and to make as many commits as they like to give them a safety net as they work. At whatever interval (normally for me, it''s when a "feature" is working and passing tests) their local changes are pushed up to the repository (and merged if necessary, but if they''ve been doing lots of little commits, the merge is often done for you). At that point, cloning out features to the other branches would need to be done (probably by a dedicated person who knows the individual systems well). "propagate those changes selectively" is almost certainly going to mean a large level of manual intervention, but again, this is much easier to decipher with the incremental commits that become the signature of DVCS. Check out www.hginit.com for a very good "getting started" guide for Mercurial. I use a "Turnkey Linux" server for my Mercurial machine, but you can install it on anything and configure yourself. The benefit of the Turnkey machine is that you get up and running in about 15mins, and can play with a few different systems for comparison. http://www.turnkeylinux.org/revision-control -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Thanks guys. Based on what I''ve read so far about VCSs and especially about git I know that I can ''fork''/''clone'' the repository but I still didn''t get the answer (or I am too thick to get it) that I am looking for. Fred, I thought branches are just used for development that later on have to be merged to the master/trunk. If that is the case a branch would not be a ''version''/''fork'' from the main vanilla version because in the end it would end up merging. I might have misunderstood what you were saying? I also understand that any change to the code would have to be determined to be a ''vanilla'' feature or a specific one to the client(s) using a particular version of the application. What I need is to know if it is possible to ''push'' out mods from the vanilla version to the other ones and which VCS would allow that. I am very new to this so I might not understand *how to* do it yet but I need sort of a yes/no answer to at least know if that is possible, and optionally if it can be more or less automated. Once I have that answer it would just be a matter of getting deep into learning the tool. Thanks so much guys. Pepe On Apr 10, 9:12 am, Michael Pavling <pavl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 10 April 2010 03:25, pepe <P...-gUAqH5+0sKL6V6G2DxALlg@public.gmane.org> wrote: > > > Also take into consideration that we have never used a version control > > system so my questions might just be due to lack of knowledge and/or > > understanding as of how to use the VCS. > > Well, distributed version control is going to be your friend here, but > you are going from a standing start to pretty much the most > complicated use of it. > > Personally, I''m a Mercurial fan, but Git is very similar. Either way, > both tools allow developers to maintain their own clones of a central > repository, and to make as many commits as they like to give them a > safety net as they work. At whatever interval (normally for me, it''s > when a "feature" is working and passing tests) their local changes are > pushed up to the repository (and merged if necessary, but if they''ve > been doing lots of little commits, the merge is often done for you). > > At that point, cloning out features to the other branches would need > to be done (probably by a dedicated person who knows the individual > systems well). "propagate those changes selectively" is almost > certainly going to mean a large level of manual intervention, but > again, this is much easier to decipher with the incremental commits > that become the signature of DVCS. > > Check outwww.hginit.comfor a very good "getting started" guide for Mercurial. > I use a "Turnkey Linux" server for my Mercurial machine, but you can > install it on anything and configure yourself. The benefit of the > Turnkey machine is that you get up and running in about 15mins, and > can play with a few different systems for comparison.http://www.turnkeylinux.org/revision-control-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
To echo what others have said here you are going to want to use a distributed version control system for this and the two most popular are Git and Mercurial. Both do what you want equally well but Mercurial is (IMO) simpler to learn and use as it has some implicit assumptions that Git does not. There is am O''Reilly book on Mercurial and a nice APress book on Git. I would read these before you deploy to decide which system more fits the features you want. Personally, I use Mercurial as I am not on a large team with complicated n-way branch/merge scenarios. If I were then I would prefer Git. As with all things in life there is a trade off between complexity and simplicity. If Mercurial does what you need you will find a smaller learning curve to get "good" at using it. I believe you would effectively want a main "branch" for the base product and an individual branch for each customer version. After you update the main branch with new features you should be able to pull those changes into the customer specific branches and rectify any issues that would effect individual customer implementations. On Apr 9, 8:25 pm, pepe <P...-1PhG29ZdMB/g+20BJ0uB2w@public.gmane.org> wrote:> Hello, > > I''m sorry if this is not the right place for this question. Please > feel free to point me in the right direction. > > Also take into consideration that we have never used a version control > system so my questions might just be due to lack of knowledge and/or > understanding as of how to use the VCS. > > Is there a version control system (be it git, TortoiseSVN, other...) > that will be able to take care of the following scenario? > > Having a ''vanilla'' version of an application we have 3 customers, each > with enough changes to their version of the application that no > version can be merged back to the vanilla one, hence ending up with 4 > versions: the vanilla one plus 3 others, one per customer. > > We need a VCS that will allow us to make changes to the main ''vanilla'' > version and propagate those changes to the other versions and, better > yet, to propagate those changes selectively, meaning to only 1, or 2, > or the 3 other versions on demand. > > Thanks in advance.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Apr 10, 2:58 pm, pepe <P...-1PhG29ZdMB/g+20BJ0uB2w@public.gmane.org> wrote:> Thanks guys. > > Based on what I''ve read so far about VCSs and especially about git I > know that I can ''fork''/''clone'' the repository but I still didn''t get > the answer (or I am too thick to get it) that I am looking for. > > Fred, I thought branches are just used for development that later on > have to be merged to the master/trunk. If that is the case a branch > would not be a ''version''/''fork'' from the main vanilla version because > in the end it would end up merging. I might have misunderstood what > you were saying?How you use branches is up to you - nothing is going to get merged unless you ask it to. Using shortlived branches for the purpose of developing a particular feature is a common strategy but that''s just a particular way of working - branches can be long lived too. (Eg the rails git repository has a 2.3.stable branch, 2.2.stable branch, and at some point will have a 3.0 stable branch. Work usually happens on master with specific changes being backported when necessary). Fred> > I also understand that any change to the code would have to be > determined to be a ''vanilla'' feature or a specific one to the > client(s) using a particular version of the application. > > What I need is to know if it is possible to ''push'' out mods from the > vanilla version to the other ones and which VCS would allow that. I am > very new to this so I might not understand *how to* do it yet but I > need sort of a yes/no answer to at least know if that is possible, and > optionally if it can be more or less automated. Once I have that > answer it would just be a matter of getting deep into learning the > tool. > > Thanks so much guys. > > Pepe > > On Apr 10, 9:12 am, Michael Pavling <pavl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > On 10 April 2010 03:25, pepe <P...-gUAqH5+0sKL6V6G2DxALlg@public.gmane.org> wrote: > > > > Also take into consideration that we have never used a version control > > > system so my questions might just be due to lack of knowledge and/or > > > understanding as of how to use the VCS. > > > Well, distributed version control is going to be your friend here, but > > you are going from a standing start to pretty much the most > > complicated use of it. > > > Personally, I''m a Mercurial fan, but Git is very similar. Either way, > > both tools allow developers to maintain their own clones of a central > > repository, and to make as many commits as they like to give them a > > safety net as they work. At whatever interval (normally for me, it''s > > when a "feature" is working and passing tests) their local changes are > > pushed up to the repository (and merged if necessary, but if they''ve > > been doing lots of little commits, the merge is often done for you). > > > At that point, cloning out features to the other branches would need > > to be done (probably by a dedicated person who knows the individual > > systems well). "propagate those changes selectively" is almost > > certainly going to mean a large level of manual intervention, but > > again, this is much easier to decipher with the incremental commits > > that become the signature of DVCS. > > > Check outwww.hginit.comfora very good "getting started" guide for Mercurial. > > I use a "Turnkey Linux" server for my Mercurial machine, but you can > > install it on anything and configure yourself. The benefit of the > > Turnkey machine is that you get up and running in about 15mins, and > > can play with a few different systems for comparison.http://www.turnkeylinux.org/revision-control-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Excellent Michael. Thank you very much for your comments. On Apr 10, 12:00 pm, MichaelF <mich...-AddfkO4XGm4dnm+yROfE0A@public.gmane.org> wrote:> To echo what others have said here you are going to want to use a > distributed version control system for this and the two most popular > are Git and Mercurial. > > Both do what you want equally well but Mercurial is (IMO) simpler to > learn and use as it has some implicit assumptions that Git does not. > There is am O''Reilly book on Mercurial and a nice APress book on Git. > I would read these before you deploy to decide which system more fits > the features you want. > > Personally, I use Mercurial as I am not on a large team with > complicated n-way branch/merge scenarios. If I were then I would > prefer Git. As with all things in life there is a trade off between > complexity and simplicity. If Mercurial does what you need you will > find a smaller learning curve to get "good" at using it. > > I believe you would effectively want a main "branch" for the base > product and an individual branch for each customer version. After you > update the main branch with new features you should be able to pull > those changes into the customer specific branches and rectify any > issues that would effect individual customer implementations. > > On Apr 9, 8:25 pm, pepe <P...-1PhG29ZdMB/g+20BJ0uB2w@public.gmane.org> wrote: > > > Hello, > > > I''m sorry if this is not the right place for this question. Please > > feel free to point me in the right direction. > > > Also take into consideration that we have never used a version control > > system so my questions might just be due to lack of knowledge and/or > > understanding as of how to use the VCS. > > > Is there a version control system (be it git, TortoiseSVN, other...) > > that will be able to take care of the following scenario? > > > Having a ''vanilla'' version of an application we have 3 customers, each > > with enough changes to their version of the application that no > > version can be merged back to the vanilla one, hence ending up with 4 > > versions: the vanilla one plus 3 others, one per customer. > > > We need a VCS that will allow us to make changes to the main ''vanilla'' > > version and propagate those changes to the other versions and, better > > yet, to propagate those changes selectively, meaning to only 1, or 2, > > or the 3 other versions on demand. > > > Thanks in advance.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Very good point Fred. Thank you all for all your comments. I really appreciate it. On Apr 10, 2:25 pm, Frederick Cheung <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Apr 10, 2:58 pm, pepe <P...-1PhG29ZdMB/g+20BJ0uB2w@public.gmane.org> wrote: > > > Thanks guys. > > > Based on what I''ve read so far about VCSs and especially about git I > > know that I can ''fork''/''clone'' the repository but I still didn''t get > > the answer (or I am too thick to get it) that I am looking for. > > > Fred, I thought branches are just used for development that later on > > have to be merged to the master/trunk. If that is the case a branch > > would not be a ''version''/''fork'' from the main vanilla version because > > in the end it would end up merging. I might have misunderstood what > > you were saying? > > How you use branches is up to you - nothing is going to get merged > unless you ask it to. Using shortlived branches for the purpose of > developing a particular feature is a common strategy but that''s just a > particular way of working - branches can be long lived too. (Eg the > rails git repository has a 2.3.stable branch, 2.2.stable branch, and > at some point will have a 3.0 stable branch. Work usually happens on > master with specific changes being backported when necessary). > > Fred > > > > > I also understand that any change to the code would have to be > > determined to be a ''vanilla'' feature or a specific one to the > > client(s) using a particular version of the application. > > > What I need is to know if it is possible to ''push'' out mods from the > > vanilla version to the other ones and which VCS would allow that. I am > > very new to this so I might not understand *how to* do it yet but I > > need sort of a yes/no answer to at least know if that is possible, and > > optionally if it can be more or less automated. Once I have that > > answer it would just be a matter of getting deep into learning the > > tool. > > > Thanks so much guys. > > > Pepe > > > On Apr 10, 9:12 am, Michael Pavling <pavl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > On 10 April 2010 03:25, pepe <P...-gUAqH5+0sKL6V6G2DxALlg@public.gmane.org> wrote: > > > > > Also take into consideration that we have never used a version control > > > > system so my questions might just be due to lack of knowledge and/or > > > > understanding as of how to use the VCS. > > > > Well, distributed version control is going to be your friend here, but > > > you are going from a standing start to pretty much the most > > > complicated use of it. > > > > Personally, I''m a Mercurial fan, but Git is very similar. Either way, > > > both tools allow developers to maintain their own clones of a central > > > repository, and to make as many commits as they like to give them a > > > safety net as they work. At whatever interval (normally for me, it''s > > > when a "feature" is working and passing tests) their local changes are > > > pushed up to the repository (and merged if necessary, but if they''ve > > > been doing lots of little commits, the merge is often done for you). > > > > At that point, cloning out features to the other branches would need > > > to be done (probably by a dedicated person who knows the individual > > > systems well). "propagate those changes selectively" is almost > > > certainly going to mean a large level of manual intervention, but > > > again, this is much easier to decipher with the incremental commits > > > that become the signature of DVCS. > > > > Check outwww.hginit.comforavery good "getting started" guide for Mercurial. > > > I use a "Turnkey Linux" server for my Mercurial machine, but you can > > > install it on anything and configure yourself. The benefit of the > > > Turnkey machine is that you get up and running in about 15mins, and > > > can play with a few different systems for comparison.http://www.turnkeylinux.org/revision-control-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.