The VXL Project

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 <matt.leotta@...>
Till: Vxl-maintainers <vxl-maintainers@...> 
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-maintainers@...
https://lists.sourceforge.net/lists/listinfo/vxl-maintainers

On Mon, Feb 20, 2012 at 6:07 PM, Matt Leotta <matt.leotta@...> 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

On Mon, 2012-02-20 at 18:27 +0100, Mathieu Malaterre wrote:
> On Mon, Feb 20, 2012 at 6:07 PM, Matt Leotta <matt.leotta@...> 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

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.

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-maintainers@... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers

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

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

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 <matt.leotta@...:

> 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-maintainers@...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>

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 <yanggehua@...> 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 <matt.leotta@...:
>
>> 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-maintainers@...
>> 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-maintainers@...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>
>

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-maintainers@... 
> 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-maintainers@...
https://lists.sourceforge.net/lists/listinfo/vxl-maintainers

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-maintainers@... 
> > 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-maintainers@...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers 
>

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.

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

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.

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

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 <matt.leotta@...:

> 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-maintainers@...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>

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 <matt.leotta@...>
> 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-maintainers@...
>         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-maintainers@... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers

OK, good idea!

 
--	Peter.


Från: Matt Leotta <matt.leotta@...>
Till: Daniel Crispell <dancrispell@...> 
Kopia: Vxl-maintainers <vxl-maintainers@...> 
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.

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

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
>

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 <scottim@...>
To: Antonio Garrido Carrillo <A.Garrido@...>
Cc: vxl-maintainers@...
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-maintainers@...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
------- End of Original Message -------

--
DEpartment of Computer Science and A.I. http://decsai.ugr.es

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-maintainers@...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers

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@...)
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.Garrido@...> 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.
>
>
> --

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@...)
> 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.Garrido@...>  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.
>>
>>
>> --

This is fine.  Thanks a lot for making the fix!

Gehua.

On Tue, Apr 17, 2012 at 3:35 AM, Antonio Garrido Carrillo
<A.Garrido@...> wrote:
> 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@...)
>> 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.Garrido@...>  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.
>>>
>>>
>>> --
>
>