On Tue, Feb 19, 2013 at 5:08 PM, Nate Coraor <nate@bx.psu.edu> wrote:

On Feb 19, 2013, at 11:23 AM, Peter Cock wrote:

...

Hi all,

I've got an hg puzzle, can anyone on the Galaxy team explain the cause of this and what action I can take to avoid it?

Starting with a clean checkout,

$ hg clone https://bitbucket.org/galaxy/galaxy-central warning: bitbucket.org certificate with fingerprint 24:9c:45:8b:9c:aa:ba:55:4e:01:6d:58:ff:e4:28:7d:2a:14:ae:3b not verified (check hostfingerprints or web.cacerts config setting) destination directory: galaxy-central requesting all changes adding changesets adding manifests adding file changes added 8886 changesets with 33822 changes to 6914 files (+1 heads) updating to branch default 4019 files updated, 0 files merged, 0 files removed, 0 files unresolved

$ cd galaxy-central

$ hg branch default

$ hg branches default 8885:9852dd712f5c stable 8880:8da37d3985ab

$ hg checkout stable abort: path 'static/june_2007_style/Makefile' traverses symbolic link 'static/june_2007_style'

I was actually trying to checkout one of my own branches, having setup the .hg/hgrc to include a link to my own fork on bitbucket.

Hi Peter,

This is due to the annoying way in which Mercurial handles symlinks. We're going to graft the changesets that caused this up to stable shortly, but in the meantime, you can do:

% rm static/june_2007_style % hg update stable --clean

This would remove any uncommitted local changes, if you had any, so it's not safe for all scenarios. But it's fine here since you're working on a fresh clone with no changes.

Cheers Nate, that trick seems to work. I'm guessing this recent commit (11 days ago) is part of the issue: https://bitbucket.org/galaxy/galaxy-central/commits/506484344db3a370f8ae2409... I hope this won't require any 'grafting' for those of us working from the default branch? Will I be safe merging the 'default' into my own branch, or should I wait while you guys sort out whatever you need to do first? Thanks, Peter

On Tue, Feb 19, 2013 at 5:26 PM, Nate Coraor <nate@bx.psu.edu> wrote:

On Feb 19, 2013, at 12:18 PM, Peter Cock wrote: Nate wrote:

...

...

Hi Peter,

This is due to the annoying way in which Mercurial handles symlinks. We're going to graft the changesets that caused this up to stable shortly, but in the meantime, you can do:

% rm static/june_2007_style % hg update stable --clean

This would remove any uncommitted local changes, if you had any, so it's not safe for all scenarios. But it's fine here since you're working on a fresh clone with no changes.

Cheers Nate, that trick seems to work.

I'm guessing this recent commit (11 days ago) is part of the issue: https://bitbucket.org/galaxy/galaxy-central/commits/506484344db3a370f8ae2409...

Indeed, that, and the previous commit.

...

I hope this won't require any 'grafting' for those of us working from the default branch? Will I be safe merging the 'default' into my own branch, or should I wait while you guys sort out whatever you need to do first?

It shouldn't require you to do anything. The only complications that should arise will be if you have changes to files under static/june_2007_style/

I've not touched that, so that's all good news - thank you :) Peter

Hey Peter, Hopefully Nate will have some wisdom, all I have is a workaround (I have fought with this on multiple forks and this is the best I have come up with). Check out a clean version of the tools branch somehow (it seems like the working contents can get stuck in an invalid state that update and checkout cannot recover from). Once you are back to a good state, it works when you merge in two steps. hg checkout tools hg merge -r ee389d2 hg ci -m "Partial merge." # Not sure if this step is needed. hg merge default -John On Thu, Apr 11, 2013 at 10:47 AM, Peter Cock <p.j.a.cock@googlemail.com> wrote:

(Apologies if this comes twice - it seems I didn't press send when I wrote the draft earlier in the week)

On Tue, Feb 19, 2013 at 5:38 PM, Peter Cock <p.j.a.cock@googlemail.com> wrote:

...

On Tue, Feb 19, 2013 at 5:26 PM, Nate Coraor <nate@bx.psu.edu> wrote:

...

On Feb 19, 2013, at 12:18 PM, Peter Cock wrote: Nate wrote:

...

...

Hi Peter,

This is due to the annoying way in which Mercurial handles symlinks. We're going to graft the changesets that caused this up to stable shortly, but in the meantime, you can do:

% rm static/june_2007_style % hg update stable --clean

This would remove any uncommitted local changes, if you had any, so it's not safe for all scenarios. But it's fine here since you're working on a fresh clone with no changes.

Cheers Nate, that trick seems to work.

I'm guessing this recent commit (11 days ago) is part of the issue: https://bitbucket.org/galaxy/galaxy-central/commits/506484344db3a370f8ae2409...

Indeed, that, and the previous commit.

...

I hope this won't require any 'grafting' for those of us working from the default branch? Will I be safe merging the 'default' into my own branch, or should I wait while you guys sort out whatever you need to do first?

It shouldn't require you to do anything. The only complications that should arise will be if you have changes to files under static/june_2007_style/

I've not touched that, so that's all good news - thank you :)

Peter

It seems I've not updated my 'tools' development branch with the 'default' branch changes since this sym link issue.

So I've switched to the default branch, done a pull, and this is now all up to date.

$ hg checkout default --clean 0 files updated, 0 files merged, 0 files removed, 0 files unresolved

$ hg update --clean 0 files updated, 0 files merged, 0 files removed, 0 files unresolved

$ hg tip changeset: 10037:ce3143a06f21 tag: tip user: jeremy goecks <jeremy.goecks@emory.edu> date: Fri Apr 05 09:39:05 2013 -0400 summary: Implement a reference-based compression approach for encoding aligned reads' sequence and cigar. Move cigar functions into own file.

$ hg diff (nothing)

At this point I would normally do: hg checkout tools, hg merge default

$ hg checkout tools abort: path 'static/june_2007_style/Makefile' traverses symbolic link 'static/june_2007_style'

So, trying the trick from before:

$ rm static/june_2007_style $ hg checkout tools abort: crosses branches (merge branches or use --clean to discard changes) $ hg checkout tools --clean 769 files updated, 0 files merged, 413 files removed, 0 files unresolved

And now, the stumbling block:

$ hg merge default merging datatypes_conf.xml.sample merging lib/galaxy/datatypes/registry.py merging lib/galaxy/jobs/__init__.py merging run.sh merging static/june_2007_style/blue/base.css and static/style/blue/base.css to static/style/blue/base.css merging tool_conf.xml.sample merging tools/filters/cutWrapper.pl abort: No such file or directory: /mnt/galaxy/galaxy-central/static/style/blue/base.css

Advice from an hg guru would be appreciated.

Thanks,

Peter ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/

To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/

On Apr 11, 2013, at 12:39 PM, Peter Cock wrote:

On Thu, Apr 11, 2013 at 5:02 PM, John Chilton <chilton@msi.umn.edu> wrote:

...

Hey Peter,

Hopefully Nate will have some wisdom, all I have is a workaround (I have fought with this on multiple forks and this is the best I have come up with).

Check out a clean version of the tools branch somehow (it seems like the working contents can get stuck in an invalid state that update and checkout cannot recover from). Once you are back to a good state, it works when you merge in two steps.

hg checkout tools hg merge -r ee389d2 hg ci -m "Partial merge." # Not sure if this step is needed. hg merge default

-John

I don't understand quite what it is doing, but it seems to have worked on a quick test repository (I re-cloned Galaxy and my fork on bitbucket). I've not just push any of these changes to bitbucket - they're all still local to this experiment for now.

Unless I hit an issue or Nate has some alternative recommendations, I'll probably do this tomorrow (its home time here in the UK).

Thanks John,

Peter

Hi Peter, I don't see any problems with this. You are merging twice, but simply doing so from two different points in the timeline. Thanks for the solution, John. --nate

I ran into the same problem as Peter, and you're post was very helpful John. Thanks for the workaround! Lance Peter Cock wrote:

On Thu, Apr 11, 2013 at 5:02 PM, John Chilton<chilton@msi.umn.edu> wrote:

...

Hey Peter,

Hopefully Nate will have some wisdom, all I have is a workaround (I have fought with this on multiple forks and this is the best I have come up with).

Check out a clean version of the tools branch somehow (it seems like the working contents can get stuck in an invalid state that update and checkout cannot recover from). Once you are back to a good state, it works when you merge in two steps.

hg checkout tools hg merge -r ee389d2 hg ci -m "Partial merge." # Not sure if this step is needed. hg merge default

-John

I don't understand quite what it is doing, but it seems to have worked on a quick test repository (I re-cloned Galaxy and my fork on bitbucket). I've not just push any of these changes to bitbucket - they're all still local to this experiment for now.

Unless I hit an issue or Nate has some alternative recommendations, I'll probably do this tomorrow (its home time here in the UK).

Thanks John,

Peter ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/

To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/

-- Lance Parsons - Scientific Programmer 134 Carl C. Icahn Laboratory Lewis-Sigler Institute for Integrative Genomics Princeton University