Re: [DISCUSS] Move Apache.NMS project to Git

[Timothy Bish]

On 02/22/2017 11:47 AM, Clebert Suconic wrote:

I think it would be simpler to have the releases aligned as it creates
a DLL Version Hell (that's an actual term on Windows/ActiveX) when you
update versions dependencies.


I can clearly see this made up scenario in a real life / customer scenario:

"Hypothetical: "NMS.ActiveMQ is dependent on NMS 1.1 as it has a bug
fix  on the NMS, while NMS.Stomp 1.3 still depending on NMS 1.0 as it
didn't need a certain bug fix... etc.. etc..."


Aligning these versions would be easier for users IMHO. But that's a
separate discussion.


It doesn't really work that way in the NMS client library releases and 
it isn't necessary given the way the release artifacts are built and 
versioned.






On Wed, Feb 22, 2017 at 11:37 AM, Christopher Shannon
 wrote:

Thanks for the clarification Tim, I missed your message from yesterday.  So
yeah in that case if we do the migration then it makes sense to me to just
create a separate git repo for each one.

On Wed, Feb 22, 2017 at 11:23 AM, Timothy Bish  wrote:


On 02/22/2017 10:47 AM, Christopher Shannon wrote:


Also, if each NMS sub project has a different version than maybe it would
actually be better to have a separate repo for each one.  That might be a
pain to manage though but would make the releases independent.


They already are in separate repos now.

https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS/
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Ap
ache.NMS.ActiveMQ/
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Ap
ache.NMS.Stomp/

etc.


On Wed, Feb 22, 2017 at 10:16 AM, Daniel Kulp  wrote:

On Feb 21, 2017, at 9:11 PM, Jim Gomes  wrote:

I guess I didn't explain the requirements clearly. Tagging is not the
solution.  This is about automatically injecting the revision of the


source


code that was used to build the product.  For example, let's say the
Subversion repository is at revision number 18634.  I am building
Apache.NMS version 1.7.0.  When I run my build, it will automatically
produce an assembly with the embedded version number 1.7.0.18634.  That
last number can't be a hash.


Why can’t it be a hash?  Or at least the git short hash?   That’s the
exact revision id for git so if that is what the purpose is, then that is
what should go there.


If I were to commit any change at all (not

necessarily creating a tag or branch, just a change), then the
repository
would increment to 18635.  If I build again, it would produce Apache.NMS
1.7.0.18635. Automatically.  This way there is no confusion as to what
exact revisions went into creating that assembly, and I have a


reproducible


build.


And the has accomplishes the same thing if the goal is a reproducible
build.


--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com




--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/








--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

Re: [DISCUSS] Move Apache.NMS project to Git

[Clebert Suconic]

I think it would be simpler to have the releases aligned as it creates
a DLL Version Hell (that's an actual term on Windows/ActiveX) when you
update versions dependencies.


I can clearly see this made up scenario in a real life / customer scenario:

"Hypothetical: "NMS.ActiveMQ is dependent on NMS 1.1 as it has a bug
fix  on the NMS, while NMS.Stomp 1.3 still depending on NMS 1.0 as it
didn't need a certain bug fix... etc.. etc..."


Aligning these versions would be easier for users IMHO. But that's a
separate discussion.




On Wed, Feb 22, 2017 at 11:37 AM, Christopher Shannon
 wrote:
> Thanks for the clarification Tim, I missed your message from yesterday.  So
> yeah in that case if we do the migration then it makes sense to me to just
> create a separate git repo for each one.
>
> On Wed, Feb 22, 2017 at 11:23 AM, Timothy Bish  wrote:
>
>> On 02/22/2017 10:47 AM, Christopher Shannon wrote:
>>
>>> Also, if each NMS sub project has a different version than maybe it would
>>> actually be better to have a separate repo for each one.  That might be a
>>> pain to manage though but would make the releases independent.
>>>
>>
>> They already are in separate repos now.
>>
>> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS/
>> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Ap
>> ache.NMS.ActiveMQ/
>> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Ap
>> ache.NMS.Stomp/
>>
>> etc.
>>
>>
>> On Wed, Feb 22, 2017 at 10:16 AM, Daniel Kulp  wrote:
>>>
>>> On Feb 21, 2017, at 9:11 PM, Jim Gomes  wrote:
>
> I guess I didn't explain the requirements clearly. Tagging is not the
> solution.  This is about automatically injecting the revision of the
>
 source

> code that was used to build the product.  For example, let's say the
> Subversion repository is at revision number 18634.  I am building
> Apache.NMS version 1.7.0.  When I run my build, it will automatically
> produce an assembly with the embedded version number 1.7.0.18634.  That
> last number can't be a hash.
>
 Why can’t it be a hash?  Or at least the git short hash?   That’s the
 exact revision id for git so if that is what the purpose is, then that is
 what should go there.


 If I were to commit any change at all (not
> necessarily creating a tag or branch, just a change), then the
> repository
> would increment to 18635.  If I build again, it would produce Apache.NMS
> 1.7.0.18635. Automatically.  This way there is no confusion as to what
> exact revisions went into creating that assembly, and I have a
>
 reproducible

> build.
>
 And the has accomplishes the same thing if the goal is a reproducible
 build.


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com



>>
>> --
>> Tim Bish
>> twitter: @tabish121
>> blog: http://timbish.blogspot.com/
>>
>>



-- 
Clebert Suconic

Re: [DISCUSS] Move Apache.NMS project to Git

[Christopher Shannon]

Thanks for the clarification Tim, I missed your message from yesterday.  So
yeah in that case if we do the migration then it makes sense to me to just
create a separate git repo for each one.

On Wed, Feb 22, 2017 at 11:23 AM, Timothy Bish  wrote:

> On 02/22/2017 10:47 AM, Christopher Shannon wrote:
>
>> Also, if each NMS sub project has a different version than maybe it would
>> actually be better to have a separate repo for each one.  That might be a
>> pain to manage though but would make the releases independent.
>>
>
> They already are in separate repos now.
>
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS/
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Ap
> ache.NMS.ActiveMQ/
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Ap
> ache.NMS.Stomp/
>
> etc.
>
>
> On Wed, Feb 22, 2017 at 10:16 AM, Daniel Kulp  wrote:
>>
>> On Feb 21, 2017, at 9:11 PM, Jim Gomes  wrote:

 I guess I didn't explain the requirements clearly. Tagging is not the
 solution.  This is about automatically injecting the revision of the

>>> source
>>>
 code that was used to build the product.  For example, let's say the
 Subversion repository is at revision number 18634.  I am building
 Apache.NMS version 1.7.0.  When I run my build, it will automatically
 produce an assembly with the embedded version number 1.7.0.18634.  That
 last number can't be a hash.

>>> Why can’t it be a hash?  Or at least the git short hash?   That’s the
>>> exact revision id for git so if that is what the purpose is, then that is
>>> what should go there.
>>>
>>>
>>> If I were to commit any change at all (not
 necessarily creating a tag or branch, just a change), then the
 repository
 would increment to 18635.  If I build again, it would produce Apache.NMS
 1.7.0.18635. Automatically.  This way there is no confusion as to what
 exact revisions went into creating that assembly, and I have a

>>> reproducible
>>>
 build.

>>> And the has accomplishes the same thing if the goal is a reproducible
>>> build.
>>>
>>>
>>> --
>>> Daniel Kulp
>>> dk...@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>>>
>>>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Re: [DISCUSS] Move Apache.NMS project to Git

[Timothy Bish]

On 02/22/2017 10:47 AM, Christopher Shannon wrote:

Also, if each NMS sub project has a different version than maybe it would
actually be better to have a separate repo for each one.  That might be a
pain to manage though but would make the releases independent.


They already are in separate repos now.

https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS/
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.ActiveMQ/
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.Stomp/

etc.


On Wed, Feb 22, 2017 at 10:16 AM, Daniel Kulp  wrote:


On Feb 21, 2017, at 9:11 PM, Jim Gomes  wrote:

I guess I didn't explain the requirements clearly. Tagging is not the
solution.  This is about automatically injecting the revision of the

source

code that was used to build the product.  For example, let's say the
Subversion repository is at revision number 18634.  I am building
Apache.NMS version 1.7.0.  When I run my build, it will automatically
produce an assembly with the embedded version number 1.7.0.18634.  That
last number can't be a hash.

Why can’t it be a hash?  Or at least the git short hash?   That’s the
exact revision id for git so if that is what the purpose is, then that is
what should go there.



If I were to commit any change at all (not
necessarily creating a tag or branch, just a change), then the repository
would increment to 18635.  If I build again, it would produce Apache.NMS
1.7.0.18635. Automatically.  This way there is no confusion as to what
exact revisions went into creating that assembly, and I have a

reproducible

build.

And the has accomplishes the same thing if the goal is a reproducible
build.


--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com





--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

Re: [DISCUSS] Move Apache.NMS project to Git

[Christopher Shannon]

Also, if each NMS sub project has a different version than maybe it would
actually be better to have a separate repo for each one.  That might be a
pain to manage though but would make the releases independent.

On Wed, Feb 22, 2017 at 10:16 AM, Daniel Kulp  wrote:

>
> > On Feb 21, 2017, at 9:11 PM, Jim Gomes  wrote:
> >
> > I guess I didn't explain the requirements clearly. Tagging is not the
> > solution.  This is about automatically injecting the revision of the
> source
> > code that was used to build the product.  For example, let's say the
> > Subversion repository is at revision number 18634.  I am building
> > Apache.NMS version 1.7.0.  When I run my build, it will automatically
> > produce an assembly with the embedded version number 1.7.0.18634.  That
> > last number can't be a hash.
>
> Why can’t it be a hash?  Or at least the git short hash?   That’s the
> exact revision id for git so if that is what the purpose is, then that is
> what should go there.
>
>
> > If I were to commit any change at all (not
> > necessarily creating a tag or branch, just a change), then the repository
> > would increment to 18635.  If I build again, it would produce Apache.NMS
> > 1.7.0.18635. Automatically.  This way there is no confusion as to what
> > exact revisions went into creating that assembly, and I have a
> reproducible
> > build.
>
> And the has accomplishes the same thing if the goal is a reproducible
> build.
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: [DISCUSS] Move Apache.NMS project to Git

[Daniel Kulp]

> On Feb 21, 2017, at 9:11 PM, Jim Gomes  wrote:
> 
> I guess I didn't explain the requirements clearly. Tagging is not the
> solution.  This is about automatically injecting the revision of the source
> code that was used to build the product.  For example, let's say the
> Subversion repository is at revision number 18634.  I am building
> Apache.NMS version 1.7.0.  When I run my build, it will automatically
> produce an assembly with the embedded version number 1.7.0.18634.  That
> last number can't be a hash.

Why can’t it be a hash?  Or at least the git short hash?   That’s the exact 
revision id for git so if that is what the purpose is, then that is what should 
go there.


> If I were to commit any change at all (not
> necessarily creating a tag or branch, just a change), then the repository
> would increment to 18635.  If I build again, it would produce Apache.NMS
> 1.7.0.18635. Automatically.  This way there is no confusion as to what
> exact revisions went into creating that assembly, and I have a reproducible
> build.

And the has accomplishes the same thing if the goal is a reproducible build.


-- 
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Re: [DISCUSS] Move Apache.NMS project to Git

[Christopher Shannon]

Jim,

I think you can accomplish both goals you are looking to achieve.

First, correct me if I am wrong but if I understand correctly, are you
saying you just want to be able to check out parts of a repo multiple times
(to have multiple branches checked out at the same time)? If so, Git lets
you do a sparse checkout so you should be able to clone the repo multiple
times but only check out certain subprojects if you want.
https://git-scm.com/docs/git-read-tree .  So if you wanted to just check
out 3 different versions you could clone the repository 3 separate times
but do a sparse checkout to only grab certain subdirectories to save space.

Second, as far as generating unique builds I think you could accomplish
this by using "lightweight tags".  A lightweight tag in git simply is a
pointer to a specifc commit and would conceptually be very similar to
assigning it a unique number based on an SVN commit.  There's almost no
overhead to creating a lightweight tag in git, it just stores the commit
checksum.  https://git-scm.com/book/en/v2/Git-Basics-Tagging  Creating a
lightweight tag for every build could be automated and would allow you to
go back to a unique build for every commit.

Chris

On Tue, Feb 21, 2017 at 9:27 PM, Clebert Suconic 
wrote:

> > So, that's a "Yes, it does duplicate the entire repository (which can be
> > quite sizeable) in order to have multiple branches checked out
> > simultaneously."  Got it. Clearly a disadvantage.
>
> I give up!!!
> We should probably migrate Artemis and AMQ5 to SVN as well.
> Pretty horrible disadvantage to have all the versions available
> without being connected.
>
> You can certainly do tricks to checkout on another directory, but it's
> just easy to copy the directory.
>
> > So, for example, I would be able to have the following structure on my
> > local hard disk?
> >
> > Apache.NMS/
> > /trunk
> > /tags
> > /1.7.0
> > /1.7.1
> > Apache.NMS.ActiveMQ/
> > /trunk
> > /tags
> > /1.7.0
> > /1.7.1
> > /1.7.2
> >
> That's messed up... horrible dependencies between versions. Even as is now.
>
> I wouldn't even bring that build style into the new project. If that's
> the case I would say keep the current SVN the way it is, and start a
> new one on git.
>

Re: [DISCUSS] Move Apache.NMS project to Git

[Clebert Suconic]

> So, that's a "Yes, it does duplicate the entire repository (which can be
> quite sizeable) in order to have multiple branches checked out
> simultaneously."  Got it. Clearly a disadvantage.

I give up!!!
We should probably migrate Artemis and AMQ5 to SVN as well.
Pretty horrible disadvantage to have all the versions available
without being connected.

You can certainly do tricks to checkout on another directory, but it's
just easy to copy the directory.

> So, for example, I would be able to have the following structure on my
> local hard disk?
>
> Apache.NMS/
> /trunk
> /tags
> /1.7.0
> /1.7.1
> Apache.NMS.ActiveMQ/
> /trunk
> /tags
> /1.7.0
> /1.7.1
> /1.7.2
>
That's messed up... horrible dependencies between versions. Even as is now.

I wouldn't even bring that build style into the new project. If that's
the case I would say keep the current SVN the way it is, and start a
new one on git.

Re: [DISCUSS] Move Apache.NMS project to Git

[Jim Gomes]

On Tue, Feb 21, 2017 at 5:07 PM Clebert Suconic 
wrote:

> > Yes, I think a Vote is a good idea.  Makes it very clear, and follows
> > established Apache process, and gives a definite cut-off point.
> >
> Ok, but so far you are the only one to be convinced.
>

It wouldn't matter if no one needed to be convinced. It has no bearing on
the process.


> > Does that duplicate the entire Git repository? It kind of looks like it
> > does.
>
> Git is very light. it is not really an issue. We do it all the time on
> many different projects.
>

So, that's a "Yes, it does duplicate the entire repository (which can be
quite sizeable) in order to have multiple branches checked out
simultaneously."  Got it. Clearly a disadvantage.


> We would likely have these sub-directories as part of the git repo:
>
> Apache.NMS/
> Apache.NMS.AMQP/
> Apache.NMS.ActiveMQ/
> Apache.NMS.ActiveMQ.Openwire.Generator/
> Apache.NMS.EMS/
> Apache.NMS.MQTT/
> Apache.NMS.MSMQ/
> Apache.NMS.Pooled/
> Apache.NMS.Stomp/
> Apache.NMS.WCF/
> Apache.NMS.XMS/
> Apache.NMS.ZMQ/
>
>
So, for example, I would be able to have the following structure on my
local hard disk?

Apache.NMS/
/trunk
/tags
/1.7.0
/1.7.1
Apache.NMS.ActiveMQ/
/trunk
/tags
/1.7.0
/1.7.1
/1.7.2

And be able to compile the trunk versions of Apache.NMS and
Apache.NMS.ActiveMQ alongside the 1.7.0 versions of Apache.NMS and 1.7.0
versions of Apache.NMS.ActiveMQ at the same time?  Also, in this situation,
the Apache.NMS.ActiveMQ 1.7.2 version imports the Apache.NMS 1.7.1 output
DLLs.

>> > repository auto-generated sequential number.  Does anyone have any
> >> > suggestions on how to accomplish a similar reproducible build using
> Git?
> >> >
> >>
> >> you don't need really need that, you can use the Hash as the version
> >> ID if you require the git.
> >>
> >> You just increment the version as everybody else does.
> >>
> >
> > I thought everyone else used the Subversion number the way I do. I
> manually
> > increment the ,  and  numbers, and generate the
> 
> > number automatically. It is not possible to embed a hash number into a
> > build number, so I'm not clear on what you are suggesting.
> >
>
> You can just tag when you make a release. It's not really an issue.
>

I guess I didn't explain the requirements clearly. Tagging is not the
solution.  This is about automatically injecting the revision of the source
code that was used to build the product.  For example, let's say the
Subversion repository is at revision number 18634.  I am building
Apache.NMS version 1.7.0.  When I run my build, it will automatically
produce an assembly with the embedded version number 1.7.0.18634.  That
last number can't be a hash.  If I were to commit any change at all (not
necessarily creating a tag or branch, just a change), then the repository
would increment to 18635.  If I build again, it would produce Apache.NMS
1.7.0.18635. Automatically.  This way there is no confusion as to what
exact revisions went into creating that assembly, and I have a reproducible
build.

I understand that revision numbers in Git are SHA1 checksums. There is no
concept of a repository revision number as there is in Subversion. Many
suggestions are to use tagging, but tagging every single check-in to
achieve the same ability does not seem like the proper use of the tool.

Re: [DISCUSS] Move Apache.NMS project to Git

[Clebert Suconic]

> I see that it has advantages,
> but it also has disadvantages.


I/You haven't found one yet.

Re: [DISCUSS] Move Apache.NMS project to Git

[Clebert Suconic]

> Yes, I think a Vote is a good idea.  Makes it very clear, and follows
> established Apache process, and gives a definite cut-off point.
>

Ok, but so far you are the only one to be convinced.


> Does that duplicate the entire Git repository? It kind of looks like it
> does.

Git is very light. it is not really an issue. We do it all the time on
many different projects.

As a matter of fact.. I constantly switch branches between 1.x and
master all the time on artemis. People do it on ActiveMQ5. If that was
a good technical reason we would need to switch back to SVN on Artemis
and ActiveMQ.. I don't think anyone would really aprove that.


However, I'm not sure if you are talking about the many directories as
part of the repo.

We would likely have these sub-directories as part of the git repo:

Apache.NMS/
Apache.NMS.AMQP/
Apache.NMS.ActiveMQ/
Apache.NMS.ActiveMQ.Openwire.Generator/
Apache.NMS.EMS/
Apache.NMS.MQTT/
Apache.NMS.MSMQ/
Apache.NMS.Pooled/
Apache.NMS.Stomp/
Apache.NMS.WCF/
Apache.NMS.XMS/
Apache.NMS.ZMQ/



Just like you do when you check-out activemq5 or artemis with all the
modules available.


>
>
>> > repository auto-generated sequential number.  Does anyone have any
>> > suggestions on how to accomplish a similar reproducible build using Git?
>> >
>>
>> you don't need really need that, you can use the Hash as the version
>> ID if you require the git.
>>
>> You just increment the version as everybody else does.
>>
>
> I thought everyone else used the Subversion number the way I do. I manually
> increment the ,  and  numbers, and generate the 
> number automatically. It is not possible to embed a hash number into a
> build number, so I'm not clear on what you are suggesting.
>

You can just tag when you make a release. It's not really an issue.


>
>> It's just a matter of you getting used with git.
>>
>
> I can get used to Git. I've used many version control systems (RCS, VCS,
> PVCS, SourceSafe, Perforce, Subversion, Mercurial, etc.). So, I look to
> those more experienced to help migrate to it. I see that it has advantages,
> but it also has disadvantages.

Re: [DISCUSS] Move Apache.NMS project to Git

[Jim Gomes]

On Tue, Feb 21, 2017 at 4:31 PM Clebert Suconic 
wrote:

> On Tue, Feb 21, 2017 at 7:09 PM, Jim Gomes  wrote:
> > As well as call a vote. A Discussion is only a discussion. It takes a
> Vote
> > to enable action.
>
> I really didn't think it would be needed.. you are the only one
> against it so far. I think we are have votes on this thread.. do you
> need it to be formal?
>

Yes, I think a Vote is a good idea.  Makes it very clear, and follows
established Apache process, and gives a definite cut-off point.


>
> > 1. I am unable to have multiple branches checked out on the machine at
> the
> > same time, which stops me from building all versions.  This is especially
> 
>
> cp -r original-directory new-directory
> cd .. new-directory
> git checokut your-other-branch
>

Does that duplicate the entire Git repository? It kind of looks like it
does.


> > repository auto-generated sequential number.  Does anyone have any
> > suggestions on how to accomplish a similar reproducible build using Git?
> >
>
> you don't need really need that, you can use the Hash as the version
> ID if you require the git.
>
> You just increment the version as everybody else does.
>

I thought everyone else used the Subversion number the way I do. I manually
increment the ,  and  numbers, and generate the 
number automatically. It is not possible to embed a hash number into a
build number, so I'm not clear on what you are suggesting.


> It's just a matter of you getting used with git.
>

I can get used to Git. I've used many version control systems (RCS, VCS,
PVCS, SourceSafe, Perforce, Subversion, Mercurial, etc.). So, I look to
those more experienced to help migrate to it. I see that it has advantages,
but it also has disadvantages.

Re: [DISCUSS] Move Apache.NMS project to Git

[Clebert Suconic]

On Tue, Feb 21, 2017 at 7:09 PM, Jim Gomes  wrote:
> As well as call a vote. A Discussion is only a discussion. It takes a Vote
> to enable action.



I really didn't think it would be needed.. you are the only one
against it so far. I think we are have votes on this thread.. do you
need it to be formal?


>
> And as far as my technical concerns go, perhaps someone more experienced
> with Git can help me solve them.  They are:
>
> 1. I am unable to have multiple branches checked out on the machine at the
> same time, which stops me from building all versions.  This is especially
> apparent when I want to build Apache.NMS trunk, and then build its
> dependencies Apache.NMS.ActiveMQ, Apache.NMS.EMS, Apache.NMS.STOMP, etc.
> How can I have all of these branches checked out at the same time if they
> are all in the same Git repository? Am I going to be forced to have
> separate Git repositories for each of those projects? Am I going to have to
> script my builds to switch branches in the middle of a hierarchical build?
> If so, that is extremely cumbersome, and not a solution I would want to go
> with.


cp -r original-directory new-directory
cd .. new-directory
git checokut your-other-branch


problem solved!


>
> 2. My entire build process is built around the automatic incrementing
> revision of Subversion (i.e., when a file is checked in, the repository
> revision number automatically increments sequentially). I use that
> automatic revision as part of the build numbers when I compile, which gives
> me completely reproducible builds.  For example, I compile a project as
> version ... where  is the Subversion
> repository auto-generated sequential number.  Does anyone have any
> suggestions on how to accomplish a similar reproducible build using Git?
>

you don't need really need that, you can use the Hash as the version
ID if you require the git.

You just increment the version as everybody else does.



> So, these are my technical issues with switching to Git.  It's not a matter
> of personal preference. So, if I can come up with solutions to these two
> items, I would have no reservations to switching to Git.  Any help is
> appreciated.

It's just a matter of you getting used with git.

Re: [DISCUSS] Move Apache.NMS project to Git

[Jim Gomes]

As well as call a vote. A Discussion is only a discussion. It takes a Vote
to enable action.

And as far as my technical concerns go, perhaps someone more experienced
with Git can help me solve them.  They are:

1. I am unable to have multiple branches checked out on the machine at the
same time, which stops me from building all versions.  This is especially
apparent when I want to build Apache.NMS trunk, and then build its
dependencies Apache.NMS.ActiveMQ, Apache.NMS.EMS, Apache.NMS.STOMP, etc.
How can I have all of these branches checked out at the same time if they
are all in the same Git repository? Am I going to be forced to have
separate Git repositories for each of those projects? Am I going to have to
script my builds to switch branches in the middle of a hierarchical build?
If so, that is extremely cumbersome, and not a solution I would want to go
with.

2. My entire build process is built around the automatic incrementing
revision of Subversion (i.e., when a file is checked in, the repository
revision number automatically increments sequentially). I use that
automatic revision as part of the build numbers when I compile, which gives
me completely reproducible builds.  For example, I compile a project as
version ... where  is the Subversion
repository auto-generated sequential number.  Does anyone have any
suggestions on how to accomplish a similar reproducible build using Git?

So, these are my technical issues with switching to Git.  It's not a matter
of personal preference. So, if I can come up with solutions to these two
items, I would have no reservations to switching to Git.  Any help is
appreciated.


On Tue, Feb 21, 2017 at 2:33 PM Timothy Bish  wrote:

> On 02/21/2017 05:23 PM, Clebert Suconic wrote:
> > I suggest you start with adding the current version there, you make
> > progress... later you cherry-pick the commits or rebase against the
> > new repo.
> >
> > This makes a lot more sense to convert it to git then.
> >
> > If I don't get any -1 in 2 days, I will assume lazy consensus and open
> > the JIRA on infra.
>
> Do you have a plan on what you are going to request?  There are actually
> several SVN repos under the NMS project and if we are migrating the AMQP
> one then I'd suggest that all be moved so you should ensure you capture
> them all.  There's also some logistics involved in the move such as
> whether the current repos be left intact in a read-only state or removed
> after the migration.  You'll also need to ensure infra migrates the
> configuration to svngit2jira for each to the new repos and  also get the
> github mirroring setup for each.
>
> There are some other tasks after that you'd need to do around ensuring
> that the repos get shifted from trunk as the root to a master branch.
>
> So before you do anything I suggest you work up a plan.
>
> >
> > On Tue, Feb 21, 2017 at 5:08 PM, Duane Pauls 
> wrote:
> >> For the NMS AMQP rework, we've created a github repo as a starting
> point:
> >> https://github.com/SolaceLabs/nms-amqp
> >>
> >> It's rather empty at the moment, but the work has been kicked off in a
> fork:
> >> https://github.com/cjwmorgan-sol-sys/nms-amqp/
> >>
> >> There isn't much there yet, but migrating to a git repository should
> make
> >> it a bit easier to migrate changes over to the Apache repo.
> >>
> >> So for me it is a (non-binding) +1.
> >>
> >> On Tue, Feb 21, 2017 at 4:51 PM, nigro_franz 
> wrote:
> >>
> >>> For me is a +1!
> >>>
> >>>
> >>>
> >>> --
> >>> View this message in context: http://activemq.2283324.n4.
> >>>
> nabble.com/DISCUSS-Move-Apache-NMS-project-to-Git-tp4722085p4722285.html
> >>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
> >>>
> >
> >
>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Re: [DISCUSS] Move Apache.NMS project to Git

[Timothy Bish]

On 02/21/2017 05:23 PM, Clebert Suconic wrote:

I suggest you start with adding the current version there, you make
progress... later you cherry-pick the commits or rebase against the
new repo.

This makes a lot more sense to convert it to git then.

If I don't get any -1 in 2 days, I will assume lazy consensus and open
the JIRA on infra.


Do you have a plan on what you are going to request?  There are actually 
several SVN repos under the NMS project and if we are migrating the AMQP 
one then I'd suggest that all be moved so you should ensure you capture 
them all.  There's also some logistics involved in the move such as 
whether the current repos be left intact in a read-only state or removed 
after the migration.  You'll also need to ensure infra migrates the 
configuration to svngit2jira for each to the new repos and  also get the 
github mirroring setup for each.


There are some other tasks after that you'd need to do around ensuring 
that the repos get shifted from trunk as the root to a master branch.


So before you do anything I suggest you work up a plan.



On Tue, Feb 21, 2017 at 5:08 PM, Duane Pauls  wrote:

For the NMS AMQP rework, we've created a github repo as a starting point:
https://github.com/SolaceLabs/nms-amqp

It's rather empty at the moment, but the work has been kicked off in a fork:
https://github.com/cjwmorgan-sol-sys/nms-amqp/

There isn't much there yet, but migrating to a git repository should make
it a bit easier to migrate changes over to the Apache repo.

So for me it is a (non-binding) +1.

On Tue, Feb 21, 2017 at 4:51 PM, nigro_franz  wrote:


For me is a +1!



--
View this message in context: http://activemq.2283324.n4.
nabble.com/DISCUSS-Move-Apache-NMS-project-to-Git-tp4722085p4722285.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.







--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

Re: [DISCUSS] Move Apache.NMS project to Git

[Clebert Suconic]

I suggest you start with adding the current version there, you make
progress... later you cherry-pick the commits or rebase against the
new repo.

This makes a lot more sense to convert it to git then.

If I don't get any -1 in 2 days, I will assume lazy consensus and open
the JIRA on infra.

On Tue, Feb 21, 2017 at 5:08 PM, Duane Pauls  wrote:
> For the NMS AMQP rework, we've created a github repo as a starting point:
> https://github.com/SolaceLabs/nms-amqp
>
> It's rather empty at the moment, but the work has been kicked off in a fork:
> https://github.com/cjwmorgan-sol-sys/nms-amqp/
>
> There isn't much there yet, but migrating to a git repository should make
> it a bit easier to migrate changes over to the Apache repo.
>
> So for me it is a (non-binding) +1.
>
> On Tue, Feb 21, 2017 at 4:51 PM, nigro_franz  wrote:
>
>> For me is a +1!
>>
>>
>>
>> --
>> View this message in context: http://activemq.2283324.n4.
>> nabble.com/DISCUSS-Move-Apache-NMS-project-to-Git-tp4722085p4722285.html
>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>>



-- 
Clebert Suconic

Re: [DISCUSS] Move Apache.NMS project to Git

[Duane Pauls]

For the NMS AMQP rework, we've created a github repo as a starting point:
https://github.com/SolaceLabs/nms-amqp

It's rather empty at the moment, but the work has been kicked off in a fork:
https://github.com/cjwmorgan-sol-sys/nms-amqp/

There isn't much there yet, but migrating to a git repository should make
it a bit easier to migrate changes over to the Apache repo.

So for me it is a (non-binding) +1.

On Tue, Feb 21, 2017 at 4:51 PM, nigro_franz  wrote:

> For me is a +1!
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/DISCUSS-Move-Apache-NMS-project-to-Git-tp4722085p4722285.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>

Re: [DISCUSS] Move Apache.NMS project to Git

[nigro_franz]

For me is a +1! 



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-Move-Apache-NMS-project-to-Git-tp4722085p4722285.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Re: [DISCUSS] Move Apache.NMS project to Git

[Clebert Suconic]

So, do we have a consensus then?

Should I just open a JIRA on Infra to make the conversion?

On Thu, Feb 16, 2017 at 11:27 AM, Christopher Shannon
 wrote:
> +1 to move the repo to Git for the same reasons already listed by others.
>
> On Thu, Feb 16, 2017 at 10:39 AM, Robbie Gemmell 
> wrote:
>
>> On 15 February 2017 at 23:41, Jim Gomes  wrote:
>> > Breaking this out into its own discussion thread...
>> >
>> > It has been proposed that Apache.NMS Subversion repository be moved to a
>> > Git repository.  While the dominate reason seems to be "that's what
>> > everyone else is doing", I'm sure there are more technical reasons for
>> the
>> > proposal. I will let others offer up those reasons for the move.
>> >
>> > As for my position, Subversion has been sufficient, but I'm not entirely
>> > opposed to the move as long as certain technical requirements can be met.
>> > These technical requirements can be entirely met if the Git repository is
>> > automatically mirrored to GitHub, which allows for Subversion clients to
>> > access a Git repository.  In that case, the port to a Git repository
>> > back-end would be completely transparent.
>> >
>> > So, let's discuss the technical merits on moving the repository to Git.
>>
>> I'd also agree that whilst moving the NMS bits to Git is not strictly
>> necessary to do such work as outlined in the propsal thread, doing so
>> would make contributing easier for many folks, especially
>> non-committers. It would also make it easier for any committers
>> participating in that process. Regardless of that, it would also be
>> nice to be consistent with all the other ActiveMQ components.
>>
>> Yes, it is true that people can use git-svn to interact with svn
>> repositories. I used to do so for many years, and still do
>> occasionally on one svn holdout (more on it below), which is a little
>> annoying. Using git-svn is definitely nicer than using svn directly,
>> but still not as nice as using Git directly. It is also something new
>> for many folks to learn when there is a high probability they are
>> using pure Git these days, and an increasing chance over time that its
>> actually all some people are familiar with.
>>
>> As Tim mentioned, it is possible to have Git and GitHub mirrors even
>> for Subversion based repositories here at Apache. There are downsides
>> to this, e.g. I've seen 15-40mins syncs to GitHub recently on the last
>> example of it over at Qpid currently (thankfully it is already slated
>> to move to Git, as everything else at Qpid has already, once some
>> in-progress tree surgery on the components is complete), however it is
>> substantially better than not having the mirrors at all. For me, its
>> less work (for us, and for infra, who would have to rework any
>> git+github mirrors again later if the source repo later moves to Git)
>> and gives a better result for most people to move it to Git at this
>> point. As you noted, GitHub allows svn clients to interact with the
>> repos which would allow a path for anyone needing svn to continue
>> using it.
>>
>> Robbie
>>



-- 
Clebert Suconic

Re: [DISCUSS] Move Apache.NMS project to Git

[Christopher Shannon]

+1 to move the repo to Git for the same reasons already listed by others.

On Thu, Feb 16, 2017 at 10:39 AM, Robbie Gemmell 
wrote:

> On 15 February 2017 at 23:41, Jim Gomes  wrote:
> > Breaking this out into its own discussion thread...
> >
> > It has been proposed that Apache.NMS Subversion repository be moved to a
> > Git repository.  While the dominate reason seems to be "that's what
> > everyone else is doing", I'm sure there are more technical reasons for
> the
> > proposal. I will let others offer up those reasons for the move.
> >
> > As for my position, Subversion has been sufficient, but I'm not entirely
> > opposed to the move as long as certain technical requirements can be met.
> > These technical requirements can be entirely met if the Git repository is
> > automatically mirrored to GitHub, which allows for Subversion clients to
> > access a Git repository.  In that case, the port to a Git repository
> > back-end would be completely transparent.
> >
> > So, let's discuss the technical merits on moving the repository to Git.
>
> I'd also agree that whilst moving the NMS bits to Git is not strictly
> necessary to do such work as outlined in the propsal thread, doing so
> would make contributing easier for many folks, especially
> non-committers. It would also make it easier for any committers
> participating in that process. Regardless of that, it would also be
> nice to be consistent with all the other ActiveMQ components.
>
> Yes, it is true that people can use git-svn to interact with svn
> repositories. I used to do so for many years, and still do
> occasionally on one svn holdout (more on it below), which is a little
> annoying. Using git-svn is definitely nicer than using svn directly,
> but still not as nice as using Git directly. It is also something new
> for many folks to learn when there is a high probability they are
> using pure Git these days, and an increasing chance over time that its
> actually all some people are familiar with.
>
> As Tim mentioned, it is possible to have Git and GitHub mirrors even
> for Subversion based repositories here at Apache. There are downsides
> to this, e.g. I've seen 15-40mins syncs to GitHub recently on the last
> example of it over at Qpid currently (thankfully it is already slated
> to move to Git, as everything else at Qpid has already, once some
> in-progress tree surgery on the components is complete), however it is
> substantially better than not having the mirrors at all. For me, its
> less work (for us, and for infra, who would have to rework any
> git+github mirrors again later if the source repo later moves to Git)
> and gives a better result for most people to move it to Git at this
> point. As you noted, GitHub allows svn clients to interact with the
> repos which would allow a path for anyone needing svn to continue
> using it.
>
> Robbie
>

Re: [DISCUSS] Move Apache.NMS project to Git

[Robbie Gemmell]

On 15 February 2017 at 23:41, Jim Gomes  wrote:
> Breaking this out into its own discussion thread...
>
> It has been proposed that Apache.NMS Subversion repository be moved to a
> Git repository.  While the dominate reason seems to be "that's what
> everyone else is doing", I'm sure there are more technical reasons for the
> proposal. I will let others offer up those reasons for the move.
>
> As for my position, Subversion has been sufficient, but I'm not entirely
> opposed to the move as long as certain technical requirements can be met.
> These technical requirements can be entirely met if the Git repository is
> automatically mirrored to GitHub, which allows for Subversion clients to
> access a Git repository.  In that case, the port to a Git repository
> back-end would be completely transparent.
>
> So, let's discuss the technical merits on moving the repository to Git.

I'd also agree that whilst moving the NMS bits to Git is not strictly
necessary to do such work as outlined in the propsal thread, doing so
would make contributing easier for many folks, especially
non-committers. It would also make it easier for any committers
participating in that process. Regardless of that, it would also be
nice to be consistent with all the other ActiveMQ components.

Yes, it is true that people can use git-svn to interact with svn
repositories. I used to do so for many years, and still do
occasionally on one svn holdout (more on it below), which is a little
annoying. Using git-svn is definitely nicer than using svn directly,
but still not as nice as using Git directly. It is also something new
for many folks to learn when there is a high probability they are
using pure Git these days, and an increasing chance over time that its
actually all some people are familiar with.

As Tim mentioned, it is possible to have Git and GitHub mirrors even
for Subversion based repositories here at Apache. There are downsides
to this, e.g. I've seen 15-40mins syncs to GitHub recently on the last
example of it over at Qpid currently (thankfully it is already slated
to move to Git, as everything else at Qpid has already, once some
in-progress tree surgery on the components is complete), however it is
substantially better than not having the mirrors at all. For me, its
less work (for us, and for infra, who would have to rework any
git+github mirrors again later if the source repo later moves to Git)
and gives a better result for most people to move it to Git at this
point. As you noted, GitHub allows svn clients to interact with the
repos which would allow a path for anyone needing svn to continue
using it.

Robbie

Re: [DISCUSS] Move Apache.NMS project to Git

[nigro_franz]

I agree for every single points!
In my past I've worked in close-sourced companies with SVN as the king of
the hill and I'm relatively new to the Git (and Github world, but now is
really impossible to think to go back.
I've found its usage so well structured and time to time simpler (Github is
a moving target around dev needs!) interact with the other developers or
work in isolation when necessary...
It is only an opinion based on my personal experience but I'm hoping will
help :)



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-Move-Apache-NMS-project-to-Git-tp4722085p4722102.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Re: [DISCUSS] Move Apache.NMS project to Git

[Clebert Suconic]

> http://blog.jthoenes.net/2011/08/01/using-git-as-frontend-for-svn/

I tried that years ago when I was still working on hornetq, and that
sucked... Horrible and really complicated to use it.
I would rather move to git completely. Once you get used with git you
won't want to get back to svn.

@Jim: It seems that you are used to SVN. Believe me.. two days after
you start working with git you won't go back.

With git you can do a lot more on interacting with other developers...

Also: there's at least one person wanting to contribute on NMS. Moving
to git will only help to build up more community around it. It's a no
brainer really IMHO.


Besides all projects are already in git.. I don't see a reason to keep
this one on SVN.



On Wed, Feb 15, 2017 at 7:25 PM, Jim Gomes  wrote:
> So, what stops people from using Git as a front-end to Subversion and
> working with the Git toolset?
>
> Here is a great write-up showing a developer doing just that:

>
> This seems like the best of both worlds.  Those that want Git, can do so
> without penalty (other than the huge local database). The same for those
> who use Subversion.
>
>
> On Wed, Feb 15, 2017 at 4:15 PM Timothy Bish  wrote:
>
>> On 02/15/2017 06:41 PM, Jim Gomes wrote:
>> > Breaking this out into its own discussion thread...
>> >
>> > It has been proposed that Apache.NMS Subversion repository be moved to a
>> > Git repository.  While the dominate reason seems to be "that's what
>> > everyone else is doing", I'm sure there are more technical reasons for
>> the
>> > proposal. I will let others offer up those reasons for the move.
>> >
>> > As for my position, Subversion has been sufficient, but I'm not entirely
>> > opposed to the move as long as certain technical requirements can be met.
>> > These technical requirements can be entirely met if the Git repository is
>> > automatically mirrored to GitHub, which allows for Subversion clients to
>> > access a Git repository.  In that case, the port to a Git repository
>> > back-end would be completely transparent.
>> >
>> > So, let's discuss the technical merits on moving the repository to Git.
>> >
>> We could move to CVS, I hear some people used to think that was
>> sufficient  ;)
>>
>> Depends on who you ask about SVN vs Git.  They both work, but I think
>> many of us have moved on to using Git for most everything we work on so
>> having to go back and muddle with SVN at this point seems an extra hurdle.
>>
>> I would say that having the ability to easily link a git based project
>> up to the Github mirror to grab PRs, apply them, push them to my github
>> mirror while testing and tweaking and them eventually merging and
>> pushing to the Activemq repo is certainly a lot simpler than muddling
>> with patches and SVN.
>>
>> It is a simple thing to have Infra mirror the NMS git repos on Github,
>> we do that already with ActiveMQ, ActiveMQ-CPP and Artemis among others.
>>
>> --
>> Tim Bish
>> twitter: @tabish121
>> blog: http://timbish.blogspot.com/
>>
>>



-- 
Clebert Suconic

Re: [DISCUSS] Move Apache.NMS project to Git

[Jim Gomes]

So, what stops people from using Git as a front-end to Subversion and
working with the Git toolset?

Here is a great write-up showing a developer doing just that:
http://blog.jthoenes.net/2011/08/01/using-git-as-frontend-for-svn/

This seems like the best of both worlds.  Those that want Git, can do so
without penalty (other than the huge local database). The same for those
who use Subversion.


On Wed, Feb 15, 2017 at 4:15 PM Timothy Bish  wrote:

> On 02/15/2017 06:41 PM, Jim Gomes wrote:
> > Breaking this out into its own discussion thread...
> >
> > It has been proposed that Apache.NMS Subversion repository be moved to a
> > Git repository.  While the dominate reason seems to be "that's what
> > everyone else is doing", I'm sure there are more technical reasons for
> the
> > proposal. I will let others offer up those reasons for the move.
> >
> > As for my position, Subversion has been sufficient, but I'm not entirely
> > opposed to the move as long as certain technical requirements can be met.
> > These technical requirements can be entirely met if the Git repository is
> > automatically mirrored to GitHub, which allows for Subversion clients to
> > access a Git repository.  In that case, the port to a Git repository
> > back-end would be completely transparent.
> >
> > So, let's discuss the technical merits on moving the repository to Git.
> >
> We could move to CVS, I hear some people used to think that was
> sufficient  ;)
>
> Depends on who you ask about SVN vs Git.  They both work, but I think
> many of us have moved on to using Git for most everything we work on so
> having to go back and muddle with SVN at this point seems an extra hurdle.
>
> I would say that having the ability to easily link a git based project
> up to the Github mirror to grab PRs, apply them, push them to my github
> mirror while testing and tweaking and them eventually merging and
> pushing to the Activemq repo is certainly a lot simpler than muddling
> with patches and SVN.
>
> It is a simple thing to have Infra mirror the NMS git repos on Github,
> we do that already with ActiveMQ, ActiveMQ-CPP and Artemis among others.
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Re: [DISCUSS] Move Apache.NMS project to Git

[Timothy Bish]

On 02/15/2017 06:41 PM, Jim Gomes wrote:

Breaking this out into its own discussion thread...

It has been proposed that Apache.NMS Subversion repository be moved to a
Git repository.  While the dominate reason seems to be "that's what
everyone else is doing", I'm sure there are more technical reasons for the
proposal. I will let others offer up those reasons for the move.

As for my position, Subversion has been sufficient, but I'm not entirely
opposed to the move as long as certain technical requirements can be met.
These technical requirements can be entirely met if the Git repository is
automatically mirrored to GitHub, which allows for Subversion clients to
access a Git repository.  In that case, the port to a Git repository
back-end would be completely transparent.

So, let's discuss the technical merits on moving the repository to Git.

We could move to CVS, I hear some people used to think that was 
sufficient  ;)


Depends on who you ask about SVN vs Git.  They both work, but I think 
many of us have moved on to using Git for most everything we work on so 
having to go back and muddle with SVN at this point seems an extra hurdle.


I would say that having the ability to easily link a git based project 
up to the Github mirror to grab PRs, apply them, push them to my github 
mirror while testing and tweaking and them eventually merging and 
pushing to the Activemq repo is certainly a lot simpler than muddling 
with patches and SVN.


It is a simple thing to have Infra mirror the NMS git repos on Github, 
we do that already with ActiveMQ, ActiveMQ-CPP and Artemis among others.


--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

Re: [DISCUSS] Move Apache.NMS project to Git

[Clebert Suconic]

> So, let's discuss the technical merits on moving the repository to Git.

It is weird to me to discuss the benefits of git. It's been a no
brainer for me for some time already. But a few I strongly believe:

- It is a better tool to accept contributions, with a better workflow.
git by itself has the hability of accepting pull requests. Github goes
a step further and makes this workflow even better.

- I was working offline earlier today without internet. moving along
several branches and committs without requiring any connectivity :)
that is a nice feature.

- Most devs are used to git these days. For those who are not, they
can use svngit mirrors.. etc...



So, I would like to just say.. +1 on doing a migration.. anyone
opposing could give us a technical reason (I don't really believe
there would be any).

[DISCUSS] Move Apache.NMS project to Git

[Jim Gomes]

Breaking this out into its own discussion thread...

It has been proposed that Apache.NMS Subversion repository be moved to a
Git repository.  While the dominate reason seems to be "that's what
everyone else is doing", I'm sure there are more technical reasons for the
proposal. I will let others offer up those reasons for the move.

As for my position, Subversion has been sufficient, but I'm not entirely
opposed to the move as long as certain technical requirements can be met.
These technical requirements can be entirely met if the Git repository is
automatically mirrored to GitHub, which allows for Subversion clients to
access a Git repository.  In that case, the port to a Git repository
back-end would be completely transparent.

So, let's discuss the technical merits on moving the repository to Git.