On Tue, Feb 21, 2017 at 5:07 PM Clebert Suconic <clebert.suco...@gmail.com>
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 <major>, <minor> and <rev> numbers, and generate the
> <build>
> > 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.
