activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Duane Pauls <>
Subject Re: [DISCUSS] Move Apache.NMS project to Git
Date Wed, 22 Feb 2017 17:05:52 GMT
On Tue, Feb 21, 2017 at 9:11 PM, Jim Gomes <> wrote:
> On Tue, Feb 21, 2017 at 5:07 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.

Jim, I'd concede it is a disadvantage.  But do you think it is a
showstopper?  I suppose there is a bit of a chicken and egg with that: it
is only a showstopper if the repository is too large, and it is hard to
know how big the repository will be until it is migrated to git.

But worst case, it sounds like there are ways to avoid duplication of the
whole repository, as described here:

Full disclosure: My own background is primarily in svn myself, so I
wouldn't take any of my git-related suggestions with any kind of
authority.  But based on my limited understanding of the above I can
imagine the solution is somewhat fragile.  But if it is for use in a
controlled loadbuild environment, perhaps it would be reliable and suitable.

> I guess I didn't explain the requirements clearly. Tagging is not the
> solution.  This is about automatically injecting the revision of the
> 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  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
> Automatically.  This way there is no confusion as to what
> exact revisions went into creating that assembly, and I have a
> 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.

Jim, if I understand you correctly, you view it as a requirement that you
be able to tell if a build is newer or older than another build within a
particular branch based on the build number?  I wonder if you could use the
output of 'git describe' to help generate the final number in your build
number as described here:

I'm not sure if there are any gotchas with this approach.  I've a git noob
-- I'm not sure if it is possible to 'inject' commits in the middle of a
branch such that v2.0-64-g835c907 today becomes v2.0-100-g835c907
tomorrow?  I agree that would be a "bad thing" if it can happen.  My
experience in working with others more familiar with git is that they tend
not to care about chronology as much as those who've used other source code
control tools.  I haven't fully wrapped my head around that yet myself

My experience is that there is a steeper learning curve with git (and I'm
definitely still on the curve).  But there are plenty of advantages.  Based
on my limited git experience, these are things I like about git:

   1. It's extremely fast to switch between branches or tags.  When working
   in svn, I often keep multiple branches or tags checked out, even if I use
   them infrequently.  With git, I'll happily switch between them.
   2. A more general statement than the above: all operations that require
   repo-side operations tend to be much faster with git because the repo is
   local.  With svn repos with large files and lots of history, I've had
   situations where it takes on the order of 1 minute to get results of 'svn
   annotate' on a file.  If you need to follow multiple merges, to get to the
   source of a particular change, this can take a long time.
   3. Perhaps not a raw git capability, but with ecosystems such as github
   and (from what I hear) Apache's git repositories, better built in support
   for distributed development.  It is easy for someone without commit access
   to submit a PR, make use of integrated tools to review the commit and have
   it get committed to the repository.

This is a very short list, and any experienced git user would probably make
the list much much longer.  But although I'm primarily an svn user myself,
I see git as being a better way to develop open source software.  However,
I can see that there are real technical hurdles that would have to be
overcome as part of the migration.  I would tend to think these challenges
can be overcome.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message