Dienstag, 20. Oktober 2009

Mercurial struggles

I've today fixed the cairo bindings, to correctly generate cubic bezier curves out of quadratic ones.

I don't see any correctness bugs running Java2Demo anymore, at least when rendering to BufferedImages - rendering to VolatileImages triggers some problems in an optimized path when using Texture/Gradient paints.

However I've real troubles publishing the code. I am working on OpenJDK revision 1421, but how do I get the latest JDK without destroying my work. I executed "hg update -C" some time ago, and all files I altered were overwritten by the files in the repo.
I've already given up maintinaing my personal xrender repo, because it caused me even more struggles.
Would be glad if some mercurial gurus could assist me.

Kommentare:

rkennke hat gesagt…

One easy way would be to hg diff > patch, then hg update -C, patch -p1 < patch and there you go.

A slightly more elegant way to do the same would be to use the MQ extension.

Quintesse hat gesagt…

But why did you do an "hg update -C"?? The docs specifically say:

Use option -C to discard all uncommitted changes (no backups!)

The standard way of working is:

hg update
hg merge
hg commit

there are other, more advanced ways, of keeping your code up-to-date with the "master" repository, but I'm no expert either.

This link does a good job of explaining the simple things in a very detailed manner:

http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html

Quintesse hat gesagt…

damn, forgot to tag the link: http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html

Linuxhippy hat gesagt…

Thanks.

However I really think mercurial hates me:

> [ce@localhost jdk2d]$ hg update
> 0 files updated, 0 files merged, 0 files removed, 0 files unresolved

Quintesse hat gesagt…

Ok, maybe me example was to simple, I left out the things I thought were obvious but of course if you've never worked with the likes of Mercurial and Git it might all seem strange. So let's start from the beginning.

When you started working on the code you obtained it from somewhere using a "pull" command, let's say:

hg pull http://some.repository/somewhere/projectX

Then you started working on the code and now you're ready to push back the changes but you first want to update your local version to the latest state of the repository you pulled your code from.

So you do the following:

hg pull http://some.repository/somewhere/projectX (to get the latest version in your local repository)
hg update (to update the files you're working on)
hg merge (to resolve any conflicts that the previous command might have caused)
hg commit (to commit your changes to your local repository)

Now you are ready to push back your changes with "push" if you've got the proper access rights to the remote repository or you could send a path (using "hg diff" like rkennke said) to its maintainer

But I really advise you to read the information at the site that I linked to in my previous message, it will make everything much clearer (and they'll explain it a lot better than I do)

PS: If you've been comitting changes to your local repository and then you do a "pull" to get the latest changes from the remote side you might need to do a "merge" immediately after doing the "pull"

PS2: If you're pulling from the same repository that you first pulled from you can leave out the URL and just do "hg pull".

Linuxhippy hat gesagt…

cool, thanks a lot ... worked flawless :)

I've already used mercurial, but always lost work after some time due to errors I made - which made me quite frustrated.

gnu_andrew hat gesagt…

I can't remember ever having to use hg update -C. Usually a hg fpull -u from the main JDK7 tree is enough to update everything, followed by a hg merge on any repos with local changesets. Others have also found hg fetch/ffetch useful (you need to enable this extension in ~/.hgrc just as you did with forest).

If you get stuck, hop into #openjdk on OFTC and someone should be able to help.