From: Matt L. <mat...@ki...> - 2012-02-20 17:07:51
|
VXL users and developers, I'd like to take a survey about the VXL community's familiarity with git and interest having VXL move from svn to git for version control. See details of the proposed move below. Please respond to the VXL maintainers mailing list if you have a strong opinion one way or the other. Answer the following two questions: What is you experience level with git? Some example responses: "none", "know about, but don't use it", "I have some limited experience with it", "I'm an experienced git user", "I already working with VXL via git-svn". Would you like to see VXL move to git? A simple "+1 for git" or "I'd rather stick with svn" response will suffice, but feel free to elaborate. Let's keep further discussion on the maintainer's mailing list. I've BCC'd this message to vxl-users to allow the broader community to take part in the survey. Proposed move of VXL from svn to git ------------------------------------ I would like to propose moving VXL from subversion to git for version control. A subset of VXL developers (including all of us at Kitware) already develop VXL using git and push changes to sourceforge using git-svn. Git is a distributed version control system and marks a substantial change in mindset from subversion (and CVS before it). If accepted, I (or someone at Kitware) will migrate the current svn repository to git in a way the preserves all the history, tags, etc. The repository will continue to be hosted at sourceforge. We will also update the website and assist others in updating dashboard builds. Kitware's build and test tools (CMake, CDash, etc.) work well with git and in fact these tools are all developed in git repositories themselves. While there are many advantages to using git over svn, the primary reason for suggesting this change now is to make stable release management easier. Git often involves a branch-and-merge workflow in which each feature is developed in a separate branch and merged into the master branch when ready. For this reason, the master branch is generally much more stable. It becomes easy to then pick which changes we want to include in the next stable release. We have found at Kitware that using git makes it much easier to manage stable releases and make them more often. I cannot cover all the benefits to git in this e-mail. It is easy to find many websites discussing them. Briefly a few other notable advantages are: 1) Each developer has a full copy of the history and most commands do not require an Internet connection. You can browse the history, make commits, etc. when you don't have an Internet connection. 2) You can easily make local commits, review all your commits for errors, revise if needed, and push all commits to the server only when they are ready. 3) Git maintains both who wrote the patch and who committed it. This allows a VXL maintainer to review the work of someone without write access (e.g. a new student) and publish those changes if acceptable. It also provided a better mechanism for accepting patches from users via e-mail. 4) Work on separate features can be separated into topic branches. While I work on my feature I can update from the server and not have to worry that someone else's changes will break my build. The only disadvantage I'm aware of with moving to git is the learning curve associated with getting all developers familiar with git. Git is an extremely powerful tool with many advanced options. Furthermore, it requires a total different mindset for thinking about version control. Git can be very confusing to a beginner, especially someone who has used the centralized model of subversion and CVS for years. However, once you really understand git, it makes development so much easier that it becomes painful to go back to svn or cvs. There are many other details that need discussion about how we would use git for VXL. Git allows for many possible workflows. There are also changes to how testing is done (e.g. which branches should we build for the dashboard?). I think it is best to leave these discussions until after it is determined that there is interest in moving to git. Thanks, Matt |
From: Peter V. <pet...@ya...> - 2012-02-20 17:26:37
|
My personal opinion (& situation) regarding git and vxl: - I have no experience whatsoever with git - My feeling is (from what I've heard from git) that git is too powerful (and too complex) for what we need with vxl collaborative development. Actually, even the move from CVS to svn was not really necessary, in my impression. Most of the add-on possibilities of svn as compared to CVS are not used by most vxl users/developers, and it became much more difficult to e.g. manipulate the local config files (CVS/Entries versus .svn/entries) in a way that does not break the client/server. For myself, the only (minor) benefit of svn is the presence on the client of the reference versions of the server file (i.e., a svn diff does not need a server connection). But the overhead (more disk space, complicated .svn directory structure) is an important con to this, more important than the advantages. git seems to go further in this direction, which (as I said) is probably more overhead for not enough return for most vxl users (and certainly myself). -- Peter. ============================================== Från: Matt Leotta <mat...@ki...> Till: Vxl-maintainers <vxl...@li...> Skickat: måndag, 20 februari 2012 18:07 Ämne: [Vxl-maintainers] Should VXL move to git? VXL users and developers, I'd like to take a survey about the VXL community's familiarity with git and interest having VXL move from svn to git for version control. See details of the proposed move below. Please respond to the VXL maintainers mailing list if you have a strong opinion one way or the other. Answer the following two questions: What is you experience level with git? Some example responses: "none", "know about, but don't use it", "I have some limited experience with it", "I'm an experienced git user", "I already working with VXL via git-svn". Would you like to see VXL move to git? A simple "+1 for git" or "I'd rather stick with svn" response will suffice, but feel free to elaborate. Let's keep further discussion on the maintainer's mailing list. I've BCC'd this message to vxl-users to allow the broader community to take part in the survey. Proposed move of VXL from svn to git ------------------------------------ I would like to propose moving VXL from subversion to git for version control. A subset of VXL developers (including all of us at Kitware) already develop VXL using git and push changes to sourceforge using git-svn. Git is a distributed version control system and marks a substantial change in mindset from subversion (and CVS before it). If accepted, I (or someone at Kitware) will migrate the current svn repository to git in a way the preserves all the history, tags, etc. The repository will continue to be hosted at sourceforge. We will also update the website and assist others in updating dashboard builds. Kitware's build and test tools (CMake, CDash, etc.) work well with git and in fact these tools are all developed in git repositories themselves. While there are many advantages to using git over svn, the primary reason for suggesting this change now is to make stable release management easier. Git often involves a branch-and-merge workflow in which each feature is developed in a separate branch and merged into the master branch when ready. For this reason, the master branch is generally much more stable. It becomes easy to then pick which changes we want to include in the next stable release. We have found at Kitware that using git makes it much easier to manage stable releases and make them more often. I cannot cover all the benefits to git in this e-mail. It is easy to find many websites discussing them. Briefly a few other notable advantages are: 1) Each developer has a full copy of the history and most commands do not require an Internet connection. You can browse the history, make commits, etc. when you don't have an Internet connection. 2) You can easily make local commits, review all your commits for errors, revise if needed, and push all commits to the server only when they are ready. 3) Git maintains both who wrote the patch and who committed it. This allows a VXL maintainer to review the work of someone without write access (e.g. a new student) and publish those changes if acceptable. It also provided a better mechanism for accepting patches from users via e-mail. 4) Work on separate features can be separated into topic branches. While I work on my feature I can update from the server and not have to worry that someone else's changes will break my build. The only disadvantage I'm aware of with moving to git is the learning curve associated with getting all developers familiar with git. Git is an extremely powerful tool with many advanced options. Furthermore, it requires a total different mindset for thinking about version control. Git can be very confusing to a beginner, especially someone who has used the centralized model of subversion and CVS for years. However, once you really understand git, it makes development so much easier that it becomes painful to go back to svn or cvs. There are many other details that need discussion about how we would use git for VXL. Git allows for many possible workflows. There are also changes to how testing is done (e.g. which branches should we build for the dashboard?). I think it is best to leave these discussions until after it is determined that there is interest in moving to git. Thanks, Matt ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Mathieu M. <mat...@gm...> - 2012-02-20 17:28:04
|
On Mon, Feb 20, 2012 at 6:07 PM, Matt Leotta <mat...@ki...> wrote: > VXL users and developers, ... > Proposed move of VXL from svn to git > ------------------------------------ > > I would like to propose moving VXL from subversion to git for version > control. A subset of VXL developers (including all of us at Kitware) > already develop VXL using git and push changes to sourceforge using > git-svn. Git is a distributed version control system and marks a > substantial change in mindset from subversion (and CVS before it). > > If accepted, I (or someone at Kitware) will migrate the current svn > repository to git in a way the preserves all the history, tags, etc. > The repository will continue to be hosted at sourceforge. We will also > update the website and assist others in updating dashboard builds. > Kitware's build and test tools (CMake, CDash, etc.) work well with git > and in fact these tools are all developed in git repositories > themselves. > > While there are many advantages to using git over svn, the primary > reason for suggesting this change now is to make stable release > management easier. Does this means you are volonteering to make the next VXL release ? Thanks -- Mathieu |
From: Matt L. <mat...@ki...> - 2012-02-20 17:49:44
|
On Mon, 2012-02-20 at 18:27 +0100, Mathieu Malaterre wrote: > On Mon, Feb 20, 2012 at 6:07 PM, Matt Leotta <mat...@ki...> wrote: > > VXL users and developers, > ... > > Proposed move of VXL from svn to git > > ------------------------------------ > > > > I would like to propose moving VXL from subversion to git for version > > control. A subset of VXL developers (including all of us at Kitware) > > already develop VXL using git and push changes to sourceforge using > > git-svn. Git is a distributed version control system and marks a > > substantial change in mindset from subversion (and CVS before it). > > > > If accepted, I (or someone at Kitware) will migrate the current svn > > repository to git in a way the preserves all the history, tags, etc. > > The repository will continue to be hosted at sourceforge. We will also > > update the website and assist others in updating dashboard builds. > > Kitware's build and test tools (CMake, CDash, etc.) work well with git > > and in fact these tools are all developed in git repositories > > themselves. > > > > While there are many advantages to using git over svn, the primary > > reason for suggesting this change now is to make stable release > > management easier. > > Does this means you are volonteering to make the next VXL release ? Well, I don't know about the next release, we are not using git yet :) More generally, though I think the answer here is yes. However, we need to get to a point where each developer has more responsibilities in forming to the release. For example, each developer needs to decide when a feature (or bug fix) they are developing is done and whether it should go into the next stable release or whether it is still a work in progress. For example, each developer would merge their git topic branches into a release candidate branch if they are ready for release. I hope we can get to the point where a release candidate branch is automatically tested on the dashboards while other branches are tested that contain ongoing development. At that point, making a new stable release is much more mechanical. If we get to that point I can volunteer to make the stable releases. --Matt |
From: Peter V. <pet...@ya...> - 2012-02-20 18:28:07
|
Matt writes: > I hope we can get to the point where a release candidate branch is > automatically tested on the dashboards while other branches are tested > that contain ongoing development. At that point, making a new stable > release is much more mechanical. If we get to that point I can > volunteer to make the stable releases. Actually, we could have done (or do) this also with CVS or svn; we've never used that possibility of CVS nor of svn, which is one of the reasons why I don't expect git will bring enough new useful features for vxl. But, in response to Matt's remark on developer's responsibility: completely agree with this. Also the idea of creating branches containing "bleeding edge" versions of the source code, next to a stable main branch, seems like a good idea to incorporate into vxl. And will indeed help a lot in creating regular "tarball" stable distributions. -- Peter. |
From: Matt L. <mat...@ki...> - 2012-02-20 18:44:27
|
On Mon, 2012-02-20 at 18:27 +0000, Peter Vanroose wrote: > Matt writes: > > I hope we can get to the point where a release candidate branch is > > automatically tested on the dashboards while other branches are > tested > > that contain ongoing development. At that point, making a new > stable > > release is much more mechanical. If we get to that point I can > > volunteer to make the stable releases. > > Actually, we could have done (or do) this also with CVS or svn; > we've never used that possibility of CVS nor of svn, which is one of > the reasons why I don't expect git will bring enough new useful > features for vxl. Peter, You are correct that it is possible to have branches in subversion, but it is impractical for a large project like VXL. Switching between VXL branches in subversion is a very slow process. It requires checking out that other branch from the server, which can take several minutes with project the size of VXL. In git this operation is nearly instantaneous because no network is needed. In fact, changing branches becomes a fundamental part of working with git. I typically change branches at least 10 times a day when working with git. It just becomes part of the normal work flow and you don't think twice about doing it. --Matt > > But, in response to Matt's remark on developer's responsibility: > completely agree with this. > Also the idea of creating branches containing "bleeding edge" versions > of the source code, next to a stable main branch, seems like a good > idea to incorporate into vxl. > And will indeed help a lot in creating regular "tarball" stable > distributions. > > -- Peter. > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Bill H. <bil...@ki...> - 2012-02-20 21:52:17
|
On 2/20/2012 1:44 PM, Matt Leotta wrote: > Peter, Having made the switch to git over a year ago now with most of the projects at Ktiware, I can say that it was worth it. It is far superior to cvs/svn for collaborative development. However, it does have a somewhat steep learning curve. Git is very powerful and supports many different "work flow" options. It would take some care to come up with a work flow that works for this community. Once that is setup, the instructions can be made so that people can get going without much effort. -Bill |
From: Brad K. <bra...@ki...> - 2012-02-20 21:10:59
|
On 2/20/2012 12:07 PM, Matt Leotta wrote: > What is you experience level with git? > Some example responses: "none", "know about, but don't use it", "I have > some limited experience with it", "I'm an experienced git user", "I > already working with VXL via git-svn". I already work with VXL via git-svn. > Would you like to see VXL move to git? +1 -Brad |
From: Gehua Y. <yan...@gm...> - 2012-02-20 22:35:59
|
My experience level with git: none. Would I like to see Vxl move to git: My initial thought is no, I would rather stick to svn. However, after reading the proposal, I do see benefits that the whole community (and I) can take in the future. Though I never use git before, I do not mind exploring it at my leisure time, as long as there are detailed instructions on how to get started with git and how to get only the head (but not the whole repo) as most VXL developers are used to. Best regards, Gehua (Gary) Yang On Mon, Feb 20, 2012 at 12:07 PM, Matt Leotta <mat...@ki...>wrote: > VXL users and developers, > > I'd like to take a survey about the VXL community's familiarity with git > and interest having VXL move from svn to git for version control. See > details of the proposed move below. Please respond to the VXL > maintainers mailing list if you have a strong opinion one way or the > other. Answer the following two questions: > > What is you experience level with git? > Some example responses: "none", "know about, but don't use it", "I have > some limited experience with it", "I'm an experienced git user", "I > already working with VXL via git-svn". > > Would you like to see VXL move to git? > A simple "+1 for git" or "I'd rather stick with svn" response will > suffice, but feel free to elaborate. > > Let's keep further discussion on the maintainer's mailing list. I've > BCC'd this message to vxl-users to allow the broader community to take > part in the survey. > > > > Proposed move of VXL from svn to git > ------------------------------------ > > I would like to propose moving VXL from subversion to git for version > control. A subset of VXL developers (including all of us at Kitware) > already develop VXL using git and push changes to sourceforge using > git-svn. Git is a distributed version control system and marks a > substantial change in mindset from subversion (and CVS before it). > > If accepted, I (or someone at Kitware) will migrate the current svn > repository to git in a way the preserves all the history, tags, etc. > The repository will continue to be hosted at sourceforge. We will also > update the website and assist others in updating dashboard builds. > Kitware's build and test tools (CMake, CDash, etc.) work well with git > and in fact these tools are all developed in git repositories > themselves. > > While there are many advantages to using git over svn, the primary > reason for suggesting this change now is to make stable release > management easier. Git often involves a branch-and-merge workflow in > which each feature is developed in a separate branch and merged into the > master branch when ready. For this reason, the master branch is > generally much more stable. It becomes easy to then pick which changes > we want to include in the next stable release. We have found at Kitware > that using git makes it much easier to manage stable releases and make > them more often. > > I cannot cover all the benefits to git in this e-mail. It is easy to > find many websites discussing them. Briefly a few other notable > advantages are: > 1) Each developer has a full copy of the history and most commands do > not require an Internet connection. You can browse the history, make > commits, etc. when you don't have an Internet connection. > 2) You can easily make local commits, review all your commits for > errors, revise if needed, and push all commits to the server only when > they are ready. > 3) Git maintains both who wrote the patch and who committed it. This > allows a VXL maintainer to review the work of someone without write > access (e.g. a new student) and publish those changes if acceptable. It > also provided a better mechanism for accepting patches from users via > e-mail. > 4) Work on separate features can be separated into topic branches. > While I work on my feature I can update from the server and not have to > worry that someone else's changes will break my build. > > The only disadvantage I'm aware of with moving to git is the learning > curve associated with getting all developers familiar with git. Git is > an extremely powerful tool with many advanced options. Furthermore, it > requires a total different mindset for thinking about version control. > Git can be very confusing to a beginner, especially someone who has used > the centralized model of subversion and CVS for years. However, once > you really understand git, it makes development so much easier that it > becomes painful to go back to svn or cvs. > > There are many other details that need discussion about how we would use > git for VXL. Git allows for many possible workflows. There are also > changes to how testing is done (e.g. which branches should we build for > the dashboard?). I think it is best to leave these discussions until > after it is determined that there is interest in moving to git. > > Thanks, > Matt > > > > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Restrepo, M. <mar...@br...> - 2012-02-21 01:00:03
|
Experience level with git? I have some limited experience. Would like to see VXL move to git? +1. I think it would make it easier to work in new features that are not ready for release. This would be beneficial for developers and those waiting for a green dashboard to make a release. -Isabel On Mon, Feb 20, 2012 at 5:35 PM, Gehua Yang <yan...@gm...> wrote: > My experience level with git: > none. > > Would I like to see Vxl move to git: > My initial thought is no, I would rather stick to svn. However, after > reading the proposal, I do see benefits that the whole community (and I) > can take in the future. Though I never use git before, I do not mind > exploring it at my leisure time, as long as there are detailed instructions > on how to get started with git and how to get only the head (but not the > whole repo) as most VXL developers are used to. > > > Best regards, > Gehua (Gary) Yang > > > On Mon, Feb 20, 2012 at 12:07 PM, Matt Leotta <mat...@ki...>wrote: > >> VXL users and developers, >> >> I'd like to take a survey about the VXL community's familiarity with git >> and interest having VXL move from svn to git for version control. See >> details of the proposed move below. Please respond to the VXL >> maintainers mailing list if you have a strong opinion one way or the >> other. Answer the following two questions: >> >> What is you experience level with git? >> Some example responses: "none", "know about, but don't use it", "I have >> some limited experience with it", "I'm an experienced git user", "I >> already working with VXL via git-svn". >> >> Would you like to see VXL move to git? >> A simple "+1 for git" or "I'd rather stick with svn" response will >> suffice, but feel free to elaborate. >> >> Let's keep further discussion on the maintainer's mailing list. I've >> BCC'd this message to vxl-users to allow the broader community to take >> part in the survey. >> >> >> >> Proposed move of VXL from svn to git >> ------------------------------------ >> >> I would like to propose moving VXL from subversion to git for version >> control. A subset of VXL developers (including all of us at Kitware) >> already develop VXL using git and push changes to sourceforge using >> git-svn. Git is a distributed version control system and marks a >> substantial change in mindset from subversion (and CVS before it). >> >> If accepted, I (or someone at Kitware) will migrate the current svn >> repository to git in a way the preserves all the history, tags, etc. >> The repository will continue to be hosted at sourceforge. We will also >> update the website and assist others in updating dashboard builds. >> Kitware's build and test tools (CMake, CDash, etc.) work well with git >> and in fact these tools are all developed in git repositories >> themselves. >> >> While there are many advantages to using git over svn, the primary >> reason for suggesting this change now is to make stable release >> management easier. Git often involves a branch-and-merge workflow in >> which each feature is developed in a separate branch and merged into the >> master branch when ready. For this reason, the master branch is >> generally much more stable. It becomes easy to then pick which changes >> we want to include in the next stable release. We have found at Kitware >> that using git makes it much easier to manage stable releases and make >> them more often. >> >> I cannot cover all the benefits to git in this e-mail. It is easy to >> find many websites discussing them. Briefly a few other notable >> advantages are: >> 1) Each developer has a full copy of the history and most commands do >> not require an Internet connection. You can browse the history, make >> commits, etc. when you don't have an Internet connection. >> 2) You can easily make local commits, review all your commits for >> errors, revise if needed, and push all commits to the server only when >> they are ready. >> 3) Git maintains both who wrote the patch and who committed it. This >> allows a VXL maintainer to review the work of someone without write >> access (e.g. a new student) and publish those changes if acceptable. It >> also provided a better mechanism for accepting patches from users via >> e-mail. >> 4) Work on separate features can be separated into topic branches. >> While I work on my feature I can update from the server and not have to >> worry that someone else's changes will break my build. >> >> The only disadvantage I'm aware of with moving to git is the learning >> curve associated with getting all developers familiar with git. Git is >> an extremely powerful tool with many advanced options. Furthermore, it >> requires a total different mindset for thinking about version control. >> Git can be very confusing to a beginner, especially someone who has used >> the centralized model of subversion and CVS for years. However, once >> you really understand git, it makes development so much easier that it >> becomes painful to go back to svn or cvs. >> >> There are many other details that need discussion about how we would use >> git for VXL. Git allows for many possible workflows. There are also >> changes to how testing is done (e.g. which branches should we build for >> the dashboard?). I think it is best to leave these discussions until >> after it is determined that there is interest in moving to git. >> >> Thanks, >> Matt >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Try before you buy = See our experts in action! >> The most comprehensive online learning library for Microsoft developers >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >> Metro Style Apps, more. Free future releases when you subscribe now! >> http://p.sf.net/sfu/learndevnow-dev2 >> _______________________________________________ >> Vxl-maintainers mailing list >> Vxl...@li... >> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers >> > > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > |
From: Lianqing Yu <yu...@li...> - 2012-02-21 16:31:08
|
Matt, did you mean you change branches 10+ times a day without network connection? If no, what's the benefit of using git for tasks like change branch. I share a similar opinion to Peter and am a bit conservative as for changing version control system for VXL. In my point of view, even the reason of replacing CVS with SVN is unclear. Learning curve maybe a counterpoint. Everybody is busy these days and who has the time to learn a new software when the current one in use works? Nonetheless, I will do some search on git and may change my mind if git offers pronounced advantages to CVS/SVN by some distance. Lianqing -----原始邮件----- From: Matt Leotta Sent: Tuesday, February 21, 2012 2:44 AM To: Peter Vanroose Cc: Vxl-maintainers Subject: Re: [Vxl-maintainers] Should VXL move to git? On Mon, 2012-02-20 at 18:27 +0000, Peter Vanroose wrote: > Matt writes: > > I hope we can get to the point where a release candidate branch is > > automatically tested on the dashboards while other branches are > tested > > that contain ongoing development. At that point, making a new > stable > > release is much more mechanical. If we get to that point I can > > volunteer to make the stable releases. > > Actually, we could have done (or do) this also with CVS or svn; > we've never used that possibility of CVS nor of svn, which is one of > the reasons why I don't expect git will bring enough new useful > features for vxl. Peter, You are correct that it is possible to have branches in subversion, but it is impractical for a large project like VXL. Switching between VXL branches in subversion is a very slow process. It requires checking out that other branch from the server, which can take several minutes with project the size of VXL. In git this operation is nearly instantaneous because no network is needed. In fact, changing branches becomes a fundamental part of working with git. I typically change branches at least 10 times a day when working with git. It just becomes part of the normal work flow and you don't think twice about doing it. --Matt > > But, in response to Matt's remark on developer's responsibility: > completely agree with this. > Also the idea of creating branches containing "bleeding edge" versions > of the source code, next to a stable main branch, seems like a good > idea to incorporate into vxl. > And will indeed help a lot in creating regular "tarball" stable > distributions. > > -- Peter. > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ Vxl-maintainers mailing > list Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Matt L. <mat...@ki...> - 2012-02-21 17:27:38
|
On Wed, 2012-02-22 at 00:30 +0800, Lianqing Yu wrote: > Matt, > did you mean you change branches 10+ times a day without network connection? Yes, exactly. It is common to switch branches frequently, making commits to each branch, and even merge branches, all without any network interaction. The only time you need the network is when you publish your changes (usually sequence of commits which may branch and/or merge) to the server or download other developers changes. As an example, I may checkout branch A and make several commits on development of feature A. Then I discover a bug unrelated to feature A, so I check out the main development branch (usually called "master"). In fact I may checkout the master branch at an older point in time when the bug was first introduced. I create a new branch B off of the master branch and I make commits on that branch to fix the bug. Then I switch back to the head of the master branch and merge in branch B to apply the bug fix. Then I may switch to release candidate branch C and merge branch B into C to fix the same bug in the release candidate. I can push the updated master branch and branch C to the server to publish the bug fix without publishing my work in branch A. Then I switch back to branch A and continue my work on feature A. The above example may sound really complicated. When using SVN or CVS it is complicated and usually more trouble than it is worth. However, using git the above work flow is very easy and is the normal mode of operation. It is common to create a whole new branch just to fix a bug one line of code. In fact it makes sense to do so because that branch can then be merged into various other branches (like a release candidate branch or the main development branch) as needed. > If no, what's the benefit of using git for tasks like change branch. > I share a similar opinion to Peter and am a bit conservative as for changing > version control system for VXL. In my point of view, even the reason of > replacing CVS with SVN is unclear. Learning curve maybe a counterpoint. > Everybody is busy these days and who has the time to learn a new software > when the current one in use works? I agree that the biggest obstacle (maybe the only obstacle) is the time needed for developers to learn git. Our current use of SVN works in some sense, but it has been lacking in other areas. It has not been successful in allowing us to easily produce stable releases for VXL users. --Matt > Nonetheless, I will do some search on git and may change my mind if git > offers pronounced advantages to CVS/SVN by some distance. > > Lianqing > > -----原始邮件----- > From: Matt Leotta > Sent: Tuesday, February 21, 2012 2:44 AM > To: Peter Vanroose > Cc: Vxl-maintainers > Subject: Re: [Vxl-maintainers] Should VXL move to git? > > On Mon, 2012-02-20 at 18:27 +0000, Peter Vanroose wrote: > > Matt writes: > > > I hope we can get to the point where a release candidate branch is > > > automatically tested on the dashboards while other branches are > > tested > > > that contain ongoing development. At that point, making a new > > stable > > > release is much more mechanical. If we get to that point I can > > > volunteer to make the stable releases. > > > > Actually, we could have done (or do) this also with CVS or svn; > > we've never used that possibility of CVS nor of svn, which is one of > > the reasons why I don't expect git will bring enough new useful > > features for vxl. > > Peter, > > You are correct that it is possible to have branches in subversion, but > it is impractical for a large project like VXL. Switching between VXL > branches in subversion is a very slow process. It requires checking out > that other branch from the server, which can take several minutes with > project the size of VXL. In git this operation is nearly instantaneous > because no network is needed. In fact, changing branches becomes a > fundamental part of working with git. I typically change branches at > least 10 times a day when working with git. It just becomes part of the > normal work flow and you don't think twice about doing it. > > --Matt > > > > > > > But, in response to Matt's remark on developer's responsibility: > > completely agree with this. > > Also the idea of creating branches containing "bleeding edge" versions > > of the source code, next to a stable main branch, seems like a good > > idea to incorporate into vxl. > > And will indeed help a lot in creating regular "tarball" stable > > distributions. > > > > -- Peter. > > > > ------------------------------------------------------------------------------ > > Try before you buy = See our experts in action! > > The most comprehensive online learning library for Microsoft developers > > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > > Metro Style Apps, more. Free future releases when you subscribe now! > > http://p.sf.net/sfu/learndevnow-dev2 > > _______________________________________________ Vxl-maintainers mailing > > list Vxl...@li... > > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Peter V. <pet...@ya...> - 2012-02-21 17:55:07
|
Matt wrote: [...] As an example, I may checkout branch A and make several commits on development of feature A. [...] Then I may switch to release candidate branch C and merge branch B into C [...] Then I switch back to branch A and continue my work on feature A. >8 ----------------------- 8< Actually, I'm doing that frequently with CVS: I just create a cvs checkout of branch A in (say) subdir A. Do some work there, possibly regularly check in to the cvs server (or not). Then decide to work on (or first create) branch B: checking this out into (say) subdir B, do the necessary work there (e.g., cmake, build, test, etc.), check in or not, switch back to subtree A, etc. Eventually remove subtree A or B or both. All very transparent also with CVS. So for myself I would not need git for this purpose. Actually, I do this already frequently with vxl (and svn), viz. for the two branches "vxl-build-makefiles" and "vxl-build-dsps". -- Peter. |
From: Matt L. <mat...@ki...> - 2012-02-21 18:52:58
|
On Tue, 2012-02-21 at 17:54 +0000, Peter Vanroose wrote: > > Matt wrote: > > [...] As an example, I may checkout branch A and make several commits > on development of feature A. [...] Then I may switch to release > candidate branch C and merge branch B into C [...] Then I switch back > to branch A and continue my work on feature A. > >8 ----------------------- 8< > > Actually, I'm doing that frequently with CVS: I just create a cvs > checkout of branch A in (say) subdir A. Do some work there, possibly > regularly check in to the cvs server (or not). Then decide to work on > (or first create) branch B: checking this out into (say) subdir B, do > the necessary work there (e.g., cmake, build, test, etc.), check in or > not, switch back to subtree A, etc. Eventually remove subtree A or B > or both. > All very transparent also with CVS. So for myself I would not need git > for this purpose. > > Actually, I do this already frequently with vxl (and svn), viz. for > the two branches "vxl-build-makefiles" and "vxl-build-dsps". Peter, This seems reasonable to me for a small project, or project where the repository is stored locally (or on a fast local network). It also seems feasible for small number of long term branches, each of which you can checkout once in different subdirectories, update as needed, and never need to delete. However, it still seems infeasible to work this way if you wanted to frequently create a short lived branch in VXL just to fix a small bug, merge into the long term branches, and delete the branch. Every time you create subdir A and checkout VXL branch A you have to download all of the VXL code on branch A from sourceforge right?. How long does that take? It's been a while since I've done it, but I seem to remember it being on the order of minutes (or at least many seconds). Also, if you are concurrently working on N different features/bug-fixes this means you would maintain N different subdirectories each with a complete checkout of VXL. I assume this is to avoid the large download time cost involved with switching branches in-place. In git I usually switch between most branches in-place in a single checkout. I do keep a couple of separate checkouts (e.g. for trunk and last stable release) to avoid long rebuild times when switching between branches with large differences. For anyone who may be worried about needing to store an entire copy of the VXL history on their computer, consider this: My current checkout of the VXL source code is about 162 Mb. My git repository for VXL is 113 Mb. That means I have quick access to every revision of every branch in all of VXL's history and it takes up less disk space than one current checkout of the source tree. You download the git history once and you are done with large transfers. Better yet, one person on your downloads the git history from sourceforge once and shares it with everyone else on your faster local network. --Matt |
From: Ian S. <sc...@im...> - 2012-02-22 12:18:19
|
On 21/02/2012 18:52, Matt Leotta wrote: > In git I usually > switch between most branches in-place in a single checkout. I do keep a > couple of separate checkouts (e.g. for trunk and last stable release) to > avoid long rebuild times when switching between branches with large > differences. That is a nice feature. My experience of switching between branches in SVN has not been happy. Keeping track of which branch I'm on, and making sure my colleagues and I commit to the correct one has been difficult. And in particular, when working on two branches, it has been very difficult to apply updates back and forth between the two. Updates fail (or worse get applied twice without a detected collision) because bits of them have been cherry picked from the other branch. Keeping track of which versions, or tags are the right ones to describe that last sync has been slow and error-prone. We like the idea of regular branching in principle, and know at some point in our commercial future we are going to have to get better at it, but none of our experience with multiple working branches on SVN has been encouraging. I have even considered hiring someone and dedicating 0.1-0.5 of their time just to manage multiple builds, branches and releases within the company. If you could confirm that GIT makes all this trivially easy, without making other aspects of the update, commit, diff-checking for debugging cycle any harder, then I'd be happy to give GIT a go. Ian. |
From: Matt L. <mat...@ki...> - 2012-02-22 14:16:07
|
On Wed, 2012-02-22 at 12:18 +0000, Ian Scott wrote: > My experience of switching between branches in SVN has not been happy. > Keeping track of which branch I'm on, and making sure my colleagues and > I commit to the correct one has been difficult. And in particular, when > working on two branches, it has been very difficult to apply updates > back and forth between the two. Updates fail (or worse get applied twice > without a detected collision) because bits of them have been cherry > picked from the other branch. Keeping track of which versions, or tags > are the right ones to describe that last sync has been slow and error-prone. > > We like the idea of regular branching in principle, and know at some > point in our commercial future we are going to have to get better at it, > but none of our experience with multiple working branches on SVN has > been encouraging. I have even considered hiring someone and dedicating > 0.1-0.5 of their time just to manage multiple builds, branches and > releases within the company. If you could confirm that GIT makes all > this trivially easy, without making other aspects of the update, commit, > diff-checking for debugging cycle any harder, then I'd be happy to give > GIT a go. Ian, The short answer is yes, git makes all this easier without making the other stuff harder. Now that we at Kitware live in this world of branchy development in git, it's hard to imagine how we functioned without it. The caveat is that developers need to follow good practices about which branches to branch from and which branches to merge into. Git provides all the tools but doesn't enforce any particular work flow. Each project must define a set of guidelines to follow to avoid unnecessary merge conflicts and avoid, for example, accidentally pulling in someone else's new features when trying to merge your bug fix into a release branch. I suggest reading this article: http://nvie.com/posts/a-successful-git-branching-model/ We may want to use a similar work flow to the one in the article above. If anyone wants to do more reading about git and work flows we have a bunch of information on Kitware public wiki related to git and how git is used in our various open source projects. http://public.kitware.com/Wiki/Git --Matt |
From: Daniel C. <dan...@gm...> - 2012-03-22 13:47:38
|
Am I right to assume by the apparent death of this thread that we will be sticking with Subversion for the time being? For the record, I have no experience with git but would be willing to give it a try if it provides an easier path to more frequent stable releases. -Dan On Wed, Feb 22, 2012 at 9:15 AM, Matt Leotta <mat...@ki...>wrote: > On Wed, 2012-02-22 at 12:18 +0000, Ian Scott wrote: > > > My experience of switching between branches in SVN has not been happy. > > Keeping track of which branch I'm on, and making sure my colleagues and > > I commit to the correct one has been difficult. And in particular, when > > working on two branches, it has been very difficult to apply updates > > back and forth between the two. Updates fail (or worse get applied twice > > without a detected collision) because bits of them have been cherry > > picked from the other branch. Keeping track of which versions, or tags > > are the right ones to describe that last sync has been slow and > error-prone. > > > > We like the idea of regular branching in principle, and know at some > > point in our commercial future we are going to have to get better at it, > > but none of our experience with multiple working branches on SVN has > > been encouraging. I have even considered hiring someone and dedicating > > 0.1-0.5 of their time just to manage multiple builds, branches and > > releases within the company. If you could confirm that GIT makes all > > this trivially easy, without making other aspects of the update, commit, > > diff-checking for debugging cycle any harder, then I'd be happy to give > > GIT a go. > > Ian, > > The short answer is yes, git makes all this easier without making the > other stuff harder. Now that we at Kitware live in this world of > branchy development in git, it's hard to imagine how we functioned > without it. > > The caveat is that developers need to follow good practices about which > branches to branch from and which branches to merge into. Git provides > all the tools but doesn't enforce any particular work flow. Each > project must define a set of guidelines to follow to avoid unnecessary > merge conflicts and avoid, for example, accidentally pulling in someone > else's new features when trying to merge your bug fix into a release > branch. I suggest reading this article: > > http://nvie.com/posts/a-successful-git-branching-model/ > > We may want to use a similar work flow to the one in the article above. > If anyone wants to do more reading about git and work flows we have a > bunch of information on Kitware public wiki related to git and how git > is used in our various open source projects. > > http://public.kitware.com/Wiki/Git > > --Matt > > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Matt L. <mat...@ki...> - 2012-03-22 14:02:01
|
Dan, I've been to busy to focus on the effort recently. In summary, I received a several responses, some off-list. Most responses were either in favor of moving to git or, like you, unfamiliar with git but willing to give it a try if it improves our release process. A few people were hesitant because of the time investment it would take to learn a new system. I believe only one person felt strongly that git would add no value to the development work flow. However, the strongest opponent and most hesitant developers are all key VXL contributors, so it probably doesn't make sense to move forward under these circumstances. Maybe it would possible to make a git clone of VXL available on sourceforge as an unofficial copy that would track the official SVN repository. This is what we do internally at Kitware. It would allow developers to experiment with git and practice with it first. Then we could consider making the git repository official at a later date. Thoughts? --Matt On Thu, 2012-03-22 at 09:47 -0400, Daniel Crispell wrote: > Am I right to assume by the apparent death of this thread that we will > be sticking with Subversion for the time being? For the record, I > have no experience with git but would be willing to give it a try if > it provides an easier path to more frequent stable releases. > > > -Dan > > > On Wed, Feb 22, 2012 at 9:15 AM, Matt Leotta <mat...@ki...> > wrote: > On Wed, 2012-02-22 at 12:18 +0000, Ian Scott wrote: > > > My experience of switching between branches in SVN has not > been happy. > > Keeping track of which branch I'm on, and making sure my > colleagues and > > I commit to the correct one has been difficult. And in > particular, when > > working on two branches, it has been very difficult to apply > updates > > back and forth between the two. Updates fail (or worse get > applied twice > > without a detected collision) because bits of them have been > cherry > > picked from the other branch. Keeping track of which > versions, or tags > > are the right ones to describe that last sync has been slow > and error-prone. > > > > We like the idea of regular branching in principle, and know > at some > > point in our commercial future we are going to have to get > better at it, > > but none of our experience with multiple working branches on > SVN has > > been encouraging. I have even considered hiring someone and > dedicating > > 0.1-0.5 of their time just to manage multiple builds, > branches and > > releases within the company. If you could confirm that GIT > makes all > > this trivially easy, without making other aspects of the > update, commit, > > diff-checking for debugging cycle any harder, then I'd be > happy to give > > GIT a go. > > > Ian, > > The short answer is yes, git makes all this easier without > making the > other stuff harder. Now that we at Kitware live in this world > of > branchy development in git, it's hard to imagine how we > functioned > without it. > > The caveat is that developers need to follow good practices > about which > branches to branch from and which branches to merge into. Git > provides > all the tools but doesn't enforce any particular work flow. > Each > project must define a set of guidelines to follow to avoid > unnecessary > merge conflicts and avoid, for example, accidentally pulling > in someone > else's new features when trying to merge your bug fix into a > release > branch. I suggest reading this article: > > http://nvie.com/posts/a-successful-git-branching-model/ > > We may want to use a similar work flow to the one in the > article above. > If anyone wants to do more reading about git and work flows we > have a > bunch of information on Kitware public wiki related to git and > how git > is used in our various open source projects. > > http://public.kitware.com/Wiki/Git > > --Matt > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud > computing > also focuses on allowing computing to be delivered as a > service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Peter V. <pet...@ya...> - 2012-03-22 21:35:03
|
OK, good idea! -- Peter. Från: Matt Leotta <mat...@ki...> Till: Daniel Crispell <dan...@gm...> Kopia: Vxl-maintainers <vxl...@li...> Skickat: torsdag, 22 mars 2012 15:01 Ämne: Re: [Vxl-maintainers] Should VXL move to git? [...] Maybe it would possible to make a git clone of VXL available on sourceforge as an unofficial copy that would track the official SVN repository. This is what we do internally at Kitware. It would allow developers to experiment with git and practice with it first. Then we could consider making the git repository official at a later date. |
From: Antonio G. C. <A.G...@de...> - 2012-03-30 10:10:11
|
Hi all, A user has asked some information about vul_arg and required arguments. This user is a little disappointed with that because he can't declare the argument as required if the option_string is not 0. First, I thought "oh my god!...change vul_arg...", but I think he is right. The solution would be to add some code testing if this argument has been set or not, but the help message indicates the argument as optional. I am thinking about adding an optional argument to vul_arg, a "bool required", is a better solution... any idea why this has not been changed before? Thanks Antonio |
From: Ian S. <sc...@im...> - 2012-03-30 10:51:25
|
Antonio, It is a little annoying but only in that it forces required arguments to be unnamed and in a fixed order. And I guess that answers your last question: It is annoying, but so far not annoying enough for anyone to want to fix it. Feel free to fix it. Bear in mind that there is an assumption throughout the vul_arg implementation, along the lines of: arg is required iff option=="" or option==0 I would suggest adding your bool is_required property, and setting it to true if option=="", or vul_arg::required enum is passed during construction. The replace all the option=="" checks with is_required(). Ian. On 30/03/2012 10:54, Antonio Garrido Carrillo wrote: > > Hi all, > > A user has asked some information about vul_arg and required arguments. > This user is a little disappointed with that because he can't declare > the argument as required if the option_string is not 0. > > First, I thought "oh my god!...change vul_arg...", but I think he is > right. The solution would be to add some code testing if this argument > has been set or not, but the help message indicates the argument as > optional. > > I am thinking about adding an optional argument to vul_arg, a "bool > required", is a better solution... any idea why this has not been > changed before? > > Thanks > Antonio > |
From: Antonio G. C. <A.G...@de...> - 2012-04-02 09:55:49
|
Ian, I have just changed vul_arg. I have tried to minimize changes, and I have only include a new bool is_required in arg_base, but not a "is_required()" method. Then I have added a new constructor with a dummy parameter to indicate a "required argument which can include a non-empty flag". In order to submit the change to all maintainers, I added a test to complete test_arg.cxx, and changed the book. The idea is that you can easily evaluate the idea and propose any change if desired. Antonio. El 30/03/12 12:51, Ian Scott escribió: > Antonio, > > It is a little annoying but only in that it forces required arguments to > be unnamed and in a fixed order. And I guess that answers your last > question: It is annoying, but so far not annoying enough for anyone to > want to fix it. > > Feel free to fix it. Bear in mind that there is an assumption throughout > the vul_arg implementation, along the lines of: > > arg is required iff option=="" or option==0 > > I would suggest adding your bool is_required property, and setting it to > true if option=="", or vul_arg::required enum is passed during > construction. The replace all the option=="" checks with is_required(). > > Ian. > > On 30/03/2012 10:54, Antonio Garrido Carrillo wrote: >> Hi all, >> >> A user has asked some information about vul_arg and required arguments. >> This user is a little disappointed with that because he can't declare >> the argument as required if the option_string is not 0. >> >> First, I thought "oh my god!...change vul_arg...", but I think he is >> right. The solution would be to add some code testing if this argument >> has been set or not, but the help message indicates the argument as >> optional. >> >> I am thinking about adding an optional argument to vul_arg, a "bool >> required", is a better solution... any idea why this has not been >> changed before? >> >> Thanks >> Antonio >> > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Antonio G. C. <A.G...@de...> - 2012-03-30 14:53:01
|
Ian, I agree... not annoying enough, so, perhaps I am the one. Give me some days and I will commit some code to include required arguments... Thanks Antonio. -- OpenWebMail Project (http://openwebmail.acatysmoof.com) ---------- Original Message ----------- From: Ian Scott <sc...@im...> To: Antonio Garrido Carrillo <A.G...@de...> Cc: vxl...@li... Sent: Fri, 30 Mar 2012 11:51:28 +0100 Subject: Re: [Vxl-maintainers] why not...vul_arg and required arguments > Antonio, > > It is a little annoying but only in that it forces required arguments to > be unnamed and in a fixed order. And I guess that answers your last > question: It is annoying, but so far not annoying enough for anyone to > want to fix it. > > Feel free to fix it. Bear in mind that there is an assumption throughout > the vul_arg implementation, along the lines of: > > arg is required iff option=="" or option==0 > > I would suggest adding your bool is_required property, and setting it to > true if option=="", or vul_arg::required enum is passed during > construction. The replace all the option=="" checks with is_required(). > > Ian. > > On 30/03/2012 10:54, Antonio Garrido Carrillo wrote: > > > > Hi all, > > > > A user has asked some information about vul_arg and required arguments. > > This user is a little disappointed with that because he can't declare > > the argument as required if the option_string is not 0. > > > > First, I thought "oh my god!...change vul_arg...", but I think he is > > right. The solution would be to add some code testing if this argument > > has been set or not, but the help message indicates the argument as > > optional. > > > > I am thinking about adding an optional argument to vul_arg, a "bool > > required", is a better solution... any idea why this has not been > > changed before? > > > > Thanks > > Antonio > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers ------- End of Original Message ------- -- DEpartment of Computer Science and A.I. http://decsai.ugr.es |
From: Gehua Y. <yan...@gm...> - 2012-04-16 21:46:10
|
Hi Antonio, I am having a small trouble compiling with the new vul_arg.h. Visual Studio raised a warning: Warning 75 warning C4661: 'vul_arg<T>::required_option_type vul_arg<T>::is_required' : no suitable definition provided for explicit template instantiation request c:\vxl\src\core\vul\vul_arg.h 198 and eventually a linking error: Error 495 error LNK2001: unresolved external symbol "public: static struct vul_arg<int>::required_option_type vul_arg<int>::is_required" (?is_required@?$vul_arg@H@@2Urequired_option_type@1@A) C:\vxl\bin-vc10-x64\core\vul\tests\test_arg.obj A fix is to add this line to initialize the static member variable outside of class scope: template <class T> typename vul_arg<T>::required_option_type vul_arg<T>::is_required; // init However, I do not like this fix as it may potentially result in duplicate symbol error at linking stage if two different source files use vul_arg with the same type. I would propose to use a slightly different version: static required_option_type is_required() { return required_option_type(); } Let me know whether you are okay with this solution. Best Regards, Gehua Yang Regards, Gehua Yang On Fri, Mar 30, 2012 at 10:52 AM, Antonio Garrido Carrillo <A.G...@de...> wrote: > > > Ian, > > I agree... not annoying enough, so, perhaps I am the one. Give me some days and I will > commit some code to include required arguments... > > Thanks > Antonio. > > > -- |
From: Antonio G. C. <A.G...@de...> - 2012-04-17 07:35:29
|
Hi, You're right, I am using linux and everything worked fine. I should have taken a look at the results in Cdash... Your solution is fine but perhapsit's easier to move "is_required" to vul_arg_base, and avoid to define a function. In this case, the definition can be inserted in vul_arg.cxx. I have already changed the files according to this idea. Are you ok with this solution? Regards, Antonio El 16/04/12 23:46, Gehua Yang escribió: > Hi Antonio, > > I am having a small trouble compiling with the new vul_arg.h. Visual > Studio raised a warning: > > Warning 75 warning C4661: 'vul_arg<T>::required_option_type > vul_arg<T>::is_required' : no suitable definition provided for > explicit template instantiation request > c:\vxl\src\core\vul\vul_arg.h 198 > > and eventually a linking error: > > Error 495 error LNK2001: unresolved external symbol "public: > static struct vul_arg<int>::required_option_type > vul_arg<int>::is_required" > (?is_required@?$vul_arg@H@@2Urequired_option_type@1@A) > C:\vxl\bin-vc10-x64\core\vul\tests\test_arg.obj > > > A fix is to add this line to initialize the static member variable > outside of class scope: > > template<class T> > typename vul_arg<T>::required_option_type vul_arg<T>::is_required; // init > > > However, I do not like this fix as it may potentially result in > duplicate symbol error at linking stage if two different source files > use vul_arg with the same type. I would propose to use a slightly > different version: > static required_option_type is_required() { return required_option_type(); } > > > Let me know whether you are okay with this solution. > > > Best Regards, > Gehua Yang > > > > > > > > Regards, > Gehua Yang > > > > > > On Fri, Mar 30, 2012 at 10:52 AM, Antonio Garrido Carrillo > <A.G...@de...> wrote: >> >> Ian, >> >> I agree... not annoying enough, so, perhaps I am the one. Give me some days and I will >> commit some code to include required arguments... >> >> Thanks >> Antonio. >> >> >> -- |