[Rivet] boost.m4 BOOST_FIND_LIB

[James Monk]

Hi David,

Sorry about that.  Why can't we use named branches for feature developments - it seems like that would be the ideal use for them.  Creating a clone of the repository each time I want to add a feature seems quite inefficient, and if it is in private, is it even available to anyone except me?  Having gzip is quite useful, and I don't see that it needs to be kept private, it's just not in the main release because of potential build issues.

The jet tagging feature *shouldn't* cause a problem - it just adds a (hopefully useful!) new member function to the FastJets projection.  It has to run an UnstableFinalState projection and keep a record of which particles to tag when it applies the jet projection, so from that point of view the most conservative thing would be to roll back the changes, but there really shouldn't be any difference in the results compared to the older version.  The main issue is that the feature is not yet fully developed.  Does hg really have a problem in rolling back the changes?

cheers,

James

On 16 Jul 2013, at 14:00, David Grellscheid wrote:

> Hi all,
> 
>> There's a new branch called "gzip" with the iostreams dependency.  I
>> don't understand why, but it's also put the jet tagging stuff into
>> the default branch rather than on its own branch as it was on my
>> repository
> 
> On your own repository, it was in "default", therefore it stays in
> default.  We've got a mess now, where the jet tagging stuff cannot
> easily be untangled again. To push only the branch where you currently
> are, you need to say 'hg push -r .'.
> 
> To create a new feature, clone _trunk_ into its own directory in
> hg-private. DO NOT USE NAMED BRANCHES for feature developments.
> 
>> - I merged the trunk onto the jet-tagging, but I guess
>> this meant there was only a single tip?  Will this fix itself the
>> next time someone pushes into the repo?
> 
> No. Not if they follow the usual workflow. You have basically published
> jet-tagging now. If that is a problem, and we need to develop rivet
> without jet-tagging, work will need to be based off Frank Siegert's
> checkin 18a418573dff.
> 
> I have marked the failed merge as closed, so most users who are unaware
> should see the right behaviour. But please let me know before pushing
> stuff to the public repo.
> 
> Thanks,
> 
>   David
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> http://www.hepforge.org/lists/listinfo/rivet