Moving cairoplot from Launchpad to GitHub

[Rodrigo Araújo]

Hello everyone,

The project's been idle for a while now, and I'm sorry. But I've been trying to get back on it.

So, my first move was to move from Launchpad to GitHub. But I've had plenty of problems migrating our commit history from bazaar to git.

As I'm on a Mac now, everything seems a little harder than when I was on Ubuntu. I've already installed bazaar and git and have spent some time trying to move our commit history from bazaar to git[2]. I've also already installed the bzr fast-export plugin and the python-fastimport library[3], but I keep getting dependency problems with this last package.

I've considered adding the most recent trunk files to a new repository on git, but that'd not migrate our commit history.

Have any of you ever been faced with this kind of problem? If so, please let me know so we can get cairoplot up and running on GitHub as soon as possible.

Also, as the trunk version is stable and should've become version 1.2 a long time ago, how would you all feel if we just moved these files to a new repository on github and started using it without our old commit history?

Best regards everyone and let's get this project back :D 

[1] http://linil.wordpress.com/2008/09/16/cairoplot-11/

[2] http://dgleich.wordpress.com/2011/01/22/convert-bazaar-to-git/

[3] http://blog.whirix.com/2011/02/bzr-to-git-migration.html

--
Rodrigo Araújo

[goodm...@gmail.com]

Welcome back!

I'm glad to hear development is starting up again. I was getting worried :)

I'm not sure I can help out much at the moment, but the NLTK project
recently moved from GoogleCode to GitHub, and there was discussion on
importing history. It's not Launchpad nor bzr, but it might be
informative: http://groups.google.com/group/nltk-dev/browse_thread/thread/3e461da3c87205c8/10f1e0f42a027519

While keeping the history would be ideal, the project is perhaps young
enough that it wouldn't be a great loss, at least not compared to
delaying the reinvigoration of developer energy. Maybe an
acknowledgements message in the new history that mentions previous
contributors would be enough?

> --
> You received this message because you are subscribed to the Google Groups
> "CairoPlot" group.
> To post to this group, send email to cair...@googlegroups.com.
> To unsubscribe from this group, send email to
> cairoplot+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/cairoplot?hl=en.

--
-Michael Wayne Goodman

[Mike Rooney]

That's awesome to hear! While losing history isn't catastrophic, it doesn't seem like there should be any need. I think anyone coming to the project will find history quite useful for various purposes. If you are unable to achieve success, I've got an Ubuntu VM (I've switched to OSX as well) and can happily do it and push to GitHub for you to fork.

Let me know!

- Michael

--

[pbzRPA]

Excellent to hear the development is kicking off again. I think there
is a lot of potential.

As to the github problem. Sorry but I have no experience there.

Regards and look forward to new versions.

[Mike Rooney]

Okay, feel free to fork! https://github.com/mrooney/cairoplot/commits/master

:]

[Rodrigo Araújo]

Hello everyone,

It's great to see that you're all still interested on the project! Michael Rooney just managed to upload the commit history to github, so I'll fork it as soon as I get home. Thanks a lot Mike!

Btw, do any of you know what's the best practice to release a stable version on GitHub? I guess the right thing to do would be to release the current trunk as version 1.2 and start working on new features.

Best regards,

--

Rodrigo Araujo

[Magnun Leno]

Em Qua 07 Dez 2011 21:01:22 BRST, Rodrigo Araújo escreveu:
> Hello everyone,
>
> It's great to see that you're all still interested on the project!
> Michael Rooney just managed to upload the commit history to github, so
> I'll fork it as soon as I get home. Thanks a lot Mike!
>
> Btw, do any of you know what's the best practice to release a stable
> version on GitHub? I guess the right thing to do would be to release
> the current trunk as version 1.2 and start working on new features.
>
> Best regards,
>
> --
> Rodrigo Araujo
>
> On 07/12/2011, at 13:46, Mike Rooney <mro...@gmail.com

>> cair...@googlegroups.com <mailto:cair...@googlegroups.com>.

>> To unsubscribe from this group, send email to
>> cairoplot+...@googlegroups.com

>> <mailto:cairoplot%2Bunsu...@googlegroups.com>.

>> For more options, visit this group at
>> http://groups.google.com/group/cairoplot?hl=en.
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "CairoPlot" group.
>> To post to this group, send email to cair...@googlegroups.com

>> <mailto:cair...@googlegroups.com>.

>> To unsubscribe from this group, send email to
>> cairoplot+...@googlegroups.com

>> <mailto:cairoplot+...@googlegroups.com>.

>> For more options, visit this group at
>> http://groups.google.com/group/cairoplot?hl=en.
>
> --
> You received this message because you are subscribed to the Google
> Groups "CairoPlot" group.
> To post to this group, send email to cair...@googlegroups.com.
> To unsubscribe from this group, send email to
> cairoplot+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/cairoplot?hl=en.

Welcome back my friend! I was joining my courage to ask you if I could
fork in order to keep CairoPlot from dying. But hey, you're back!

Well about the release, I'm relatively new to GitHub too (I'm trying to
learn it), but Git has a feature called tags, you can use it to "mark"
this as release 1.2. Maybe you could also use the branches feature to
create a dev branch, with this the master branch (there is no trunk in
Git, we call master branch) will me less buggy.

Let's start working again!
PS: Stop selling your soul to Apple!!! (just joking)

[Mike Rooney]

On Wed, Dec 7, 2011 at 9:18 PM, Magnun Leno <magnu...@gmail.com> wrote:

Btw, do any of you know what's the best practice to release a stable version on GitHub? I guess the right thing to do would be to release the current trunk as version 1.2 and start working on new features.

Git does have the concept of tags, but AFAIK you can't commit to them or merge, so using them for releases would make it a pain later if you needed to commit a bug fix and release that version with it. Generally at the point at which you want to branch on master, you can just type "git branch 1.2" and you'll have created a 1.2 branch, which you can later checkout, commit a bugfix to, and merge back to master if necessary.

I've seen a bunch of Git projects just have the policy of "build from trunk or the latest branches", and another set which upload tarballs/zips for each version to the Downloads section, and either seems to work, though I always feel more confident about released Downloads.

Sorry if any of this is redundant or not useful :]

- Michael

[Magnun Leno]

On 8 dez, 02:30, Mike Rooney <mroo...@gmail.com> wrote:

The good part of using tags and etc, is that GitHub automatically
generates packages (zip or tar.gz) for it.

Indeed you're correct, you can't commit or merge to a tag. A tag is
just a marker that we can assign for an specific commit. I've recently
found this article[1] which explains nicely the basic Git workflow. I
strongly recommend that everyone read it.

I hope this will help us.

Magnun Leno
www.mindbending.org
@mind_bend

[1]: http://nvie.com/posts/a-successful-git-branching-model/

[Rodrigo Araújo]

Hey everyone,

Still on the topic of how to use Git properly, I've been reading the ProGit ebook[1].

It seems to be a very good way to understand how the tool works and how we can use it properly. I'm almost getting to the section about tagging.

But I'm surely gonna read Magnun's link.

Best regards,

[1] http://progit.org/book/

--
You received this message because you are subscribed to the Google Groups "CairoPlot" group.
To post to this group, send email to cair...@googlegroups.com.
To unsubscribe from this group, send email to cairoplot+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cairoplot?hl=en.

--
Rodrigo Araújo

[Magnus Skog]

Hey Guys,

I've been doing a lot of research on Git for work and have been using
it for about a year now. During my research on the net I've gathered a
billion links but boiled them down to the following (ProGit being one
of them naturally):

http://www.eecs.harvard.edu/~cduan/technical/git/

http://gitref.org/index.html

http://www-cs-students.stanford.edu/~blynn/gitmagic/ch01.html

http://www.spheredev.org/wiki/Git_for_the_lazy

http://gitready.com/

http://gitcasts.com/

http://book.git-scm.com/

http://excess.org/article/2008/07/ogre-git-tutorial/

Hope they can be of use. I especially recommend the Git Casts page.
It's created by Scott Chacon (the guy behind github and Pro Git).

Cheers !
/Magnus

2011/12/13 Rodrigo Araújo <alf.r...@gmail.com>:

[Rodrigo Araújo]

Hi everyone,

So, I've read the tagging section on ProGit

Tagging

Like most VCSs, Git has the ability to tag specific points in history as being important. Generally, people use this functionality to mark release points (v1.0, and so on). In this section, you’ll learn how to list the available tags, how to create new tags, and what the different types of tags are.

Git uses two main types of tags: lightweight and annotated. A lightweight tag is very much like a branch that doesn’t change — it’s just a pointer to a specific commit. Annotated tags, however, are stored as full objects in the Git database. They’re checksummed; contain the tagger name, e-mail, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG). It’s generally recommended that you create annotated tags so you can have all this information; but if you want a temporary tag or for some reason don’t want to keep the other information, lightweight tags are available too.

It doesn't explain how do we maintain these tags really well, would the problems pointed by Mike Rooney on tags still affect Annotated tags?

[Magnus Skog]

Hi,

Yes the same rules apply whether it's a lightweight or annotated, i.e.
you can't commit to it.

/Magnus

2011/12/16 Rodrigo Araújo <alf.r...@gmail.com>:

[Paul Eipper]

It works great, here is the workflow I use based on
http://nvie.com/posts/a-successful-git-branching-model/

[create new release from develop]
git checkout develop
git checkout -b release-1.0
test release code... fix... create release changelogs, etc...
git checkout master
git merge --no-ff release-1.0
git tag -a 1.0 -m "Release v.1.0"
git checkout develop
git merge --no-ff release-1.0

[create a hotfix from version 1.0]
git checkout -b hotfix-1.0.1 1.0
fix.. fix.. fix...
git checkout master
git merge --no-ff hotfix-1.0.1
git tag -a 1.0.1 -m "Release v.1.0.1"

[optionally merge hotfixes to develop branch]
git checkout develop
git merge --no-ff hotfix-1.0.1

--
Paul Eipper

[Magnus Skog]

Sweet!

One thing that is important is that tags (as well as branches) are
only local until you share them. So you must push tags the same way
you push branches.

Share individual tags (using Pauls tags):

git push origin 1.0
git push origin 1.0.1

Share all tags:

git push origin --tags

2011/12/16 Paul Eipper <lkra...@gmail.com>:

[Paul Eipper]

Don't think in svn terms, it does not work at all for git.

Lightweight tags are local markers only.
Annotated are for sharing.

And you can branch off from tags to create hotfixes and such as I
showed in my last post.

--
Paul Eipper

On Fri, Dec 16, 2011 at 12:21 PM, Magnus Skog