Thread: [Doxygen-develop] Doxygen's code repository has moved to GitHub
Brought to you by:
dimitri
Menu
▾
▴
doxygen-develop
|
From: Dimitri v. H. <di...@st...> - 2013-05-20 12:35:07
|
Hi, As of today doxygen's code repository has officially moved to GitHub! It can be found here: https://github.com/doxygen/doxygen I plan to do changes as individual commits, so it is more easy to see what code changes belong to a fix or feature. I also plan to do much more frequent pushes, so you can more quickly use and test fixes. This also means that the changelogs will no longer be posted here. Stable releases will be tagged as such and the change log is then equal to the commit log since the last tag. I still have to get a bit more familar with the possibilities and the best way of working, so any tips are welcome ;-) Enjoy, Dimitri |
|
From: Peter M. <ped...@gm...> - 2013-05-20 12:41:55
|
Best give I can give is to have the branches - master = the latest stable release - next = the next version and unstable Pete |
|
From: Petr P. <Pr...@sk...> - 2013-05-20 14:17:25
|
Hi, Peter Morgan wrote: > Best give I can give is to have the branches > - master = the latest stable release > - next = the next version and unstable I am not that sure about the neccessity of the branches when moved to Git. They should probably be created only when the branch is found to be neccessary. They can mostly be local only. I suggest to use GitHub fork mechanism to keep the project responsibility firmly in Dimitri's hands (at least at the beginning). The Pull Request seems to be visible enough to decide whether to pull or not, or to use only some changes... However, I have only limited experience with Git, and I can be wrong ;) Petr |
|
From: Petr P. <Pr...@sk...> - 2013-05-20 15:08:40
|
> [...] any tips are welcome ;-) I suggest to introduce the .gitignore file at the root level with a directory that anyone can use for whatever. The reason is that I would like to use some "private" subdirectory that is near to doxygen's everything. Sure, I can make my own fork, my own .gitignore, and I can secretly decide what the name of the directory is to be. However, the pull request/merge would not be that easy in such case. The goal is to keep the .gitignore public. Because of that, the private subdirectory should be named publicly. It can be defined via prefix and the wildcard. I suggest to put the following line to the .gitignore: __*/ i.e. two underscores, star, slash. This way, any directory that starts with two underscores will be considered private. This way, developers will be free to create whatever private subdirectory they like, wherever they like. The rule "the two-underscore prefix" is easy to explain. Petr |
|
From: Ken K. <kjk...@ya...> - 2013-05-21 00:40:28
|
On a windows machine, what is a good tool to use to get the main repo? I have been using commit monitor for the SVN repo and this tells me when there are new files and auto downloads them. Is there a similar tool for GIT? --- On Mon, 5/20/13, Jason Edgecombe <ja...@ra...> wrote: > From: Jason Edgecombe <ja...@ra...> > Subject: Re: [Doxygen-users] [Doxygen-develop] Doxygen's code repository has moved to GitHub > To: "Petr Prikryl" <Pr...@sk...> > Cc: "Peter Morgan" <ped...@gm...>, "Dimitri van Heesch" <di...@st...>, "dox...@li..." <dox...@li...>, "dox...@li..." <dox...@li...> > Date: Monday, May 20, 2013, 7:09 PM > On 05/20/2013 10:15 AM, Petr Prikryl > wrote: > > Hi, > > > > Peter Morgan wrote: > >> Best give I can give is to have the branches > >> - master = the latest stable release > >> - next = the next version and unstable > > I am not that sure about the neccessity of > > the branches when moved to Git. They should > > probably be created only when the branch > > is found to be neccessary. They can mostly > > be local only. > > > > I suggest to use GitHub fork mechanism to > > keep the project responsibility firmly > > in Dimitri's hands (at least at the beginning). > > The Pull Request seems to be visible enough > > to decide whether to pull or not, or to use > > only some changes... > > > > However, I have only limited experience > > with Git, and I can be wrong ;) > > > > Petr > > > > One of the challenges with git is that is flexible and > allows for many > work flows. There isn't one "right way", but there are some > common > workflows. > > The most common workflow that I have seen is as follows: > * most or all development happens on the master branch > * each new feature gets it's own branch, which is merged or > rebased with > the master branch when it's mostly complete and doesn't > break the build. > * releases are cut as tags from master or from a version > branch or > stable branch(i.e. potential branches: master, stable, > 1.2.x, 1.3.x, > tags: 1.2.1, 1.2.2, 1.3.1) > > My advice is somewhat contrary to Peter's: > * branches are awesome, use them whenever developing a new > feature. > Local branches can easily be discarded if things don't work > out. Use > public branches in the git repo with some reservation, > * You should use a new feature branch for each new feature > in your local > repo. Once the feature is ready for merging, then > merge/rebase and push > the changes to github. > * Using a branch allows for you to easily switch between > various > works-in-progress. > > Peter's next+master workflow is what the Linux kernel uses. > It kind of > mirrors master+stable branches in other projects. > > One alternative workflow is called git-flow, which is > outlined here: > http://nvie.com/posts/a-successful-git-branching-model/ > > One of the best ways to develop is using a continuous > integration model. > In this model, each commit to "master" is compiled and run > against a > series of tests, to determine if the project is viable. > > Travis CI offers free continuous compiling/integration for > open source > projects. It even integrates with github: > https://travis-ci.org/ > > Jason > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance > monitoring service > that delivers powerful full stack analytics. Optimize and > monitor your > browser, app, & servers with just a few lines of code. > Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > Doxygen-users mailing list > Dox...@li... > https://lists.sourceforge.net/lists/listinfo/doxygen-users > |
|
From: Peter M. <ped...@gm...> - 2013-05-21 02:14:39
|
On 21 May 2013 01:40, Ken Kazinski <kjk...@ya...> wrote: > On a windows machine, what is a good tool to use to get the main repo? I > have been using commit monitor for the SVN repo and this tells me when > there are new files and auto downloads them. Is there a similar tool for > GIT? > U can either use the github client == their proprietory and kinda an interface. http://windows.github.com/ or U can dowload the kinda native kit from http://msysgit.github.io/ ie Git for Windows The later is neat, because even the standard install gives once cd c:\myGit git clone gi...@gi.../doxygen/doxygen<https://github.com/doxygen/doxygen> git clone https://me:myP...@bi.../f<https://github.com/doxygen/doxygen> oo/secret-project The snag is in the keys.. - The bitbucket authenticaltion works as its using http auth - the git@git hub is read only.. so no problem - But is u want to commit then u need to hace the "key" installed on local matching remote - the github windows client does that for you.. ie creates a ssh key and logs u in etc - the msys client, u have to deal with that (pain) yourself.. Depending on your skill level, windows.github is probably the easiest.. and your up and running fast.. issues, merges etc and all.. as a paltform Pete |
|
From: Petr P. <Pr...@sk...> - 2013-05-21 06:45:49
|
> Ken Kazinski wrote: > On a windows machine, what is a good tool to use to get the main repo? Start with the official http://git-scm.com/ The page recognizes your OS and displays a link (button) Download for Windows. It redirects you to the latest stable msysgit. I consider that the good choice for Windows. > I have been using commit monitor for the SVN repo and this tells me > when there are new files and auto downloads them. Is there a similar > tool for GIT? The gitk and "git gui" are the tools (Tcl/Tk) for visualizing the status and the process. (There are other alternatives, but I did not need them.) "gitk --all" shows you visually what you have in your repository. Anyway, Git does not use the central repository. Your local repository is considered equal. This way, your question is "how to keep my repository up-to-date". The decision to be made is also "what branch do I want to track?". It would be better to discuss the situation based on how do you want to work with the content. Petr |
|
From: Peter M. <ped...@gm...> - 2013-05-21 01:59:32
|
Peter Morgan wrote: >> >>> Best give I can give is to have the branches >>> - master = the latest stable release >>> - next = the next version and unstable >> >> > One of the challenges with git is that is flexible and allows for many > work flows. There isn't one "right way", but there are some common > workflows. > > The most common workflow that I have seen is as follows: > * most or all development happens on the master branch > * each new feature gets it's own branch, which is merged or rebased with > the master branch when it's mostly complete and doesn't break the build. > * releases are cut as tags from master or from a version branch or stable > branch(i.e. potential branches: master, stable, 1.2.x, 1.3.x, tags: 1.2.1, > 1.2.2, 1.3.1) > Yes indeed, we need to create the tags.. I should have mentioned that.. > > My advice is somewhat contrary to Peter's: > * branches are awesome, use them whenever developing a new feature. Local > branches can easily be discarded if things don't work out. Use public > branches in the git repo with some reservation, > * You should use a new feature branch for each new feature in your local > repo. Once the feature is ready for merging, then merge/rebase and push the > changes to github. > * Using a branch allows for you to easily switch between various > works-in-progress. > Well, can I add, cos I 100% agree, there's ways of slkinning a cat/penguin with git, particular in Sweden/Finland ..;-) So the thought in my head is what "distributors" will use, eg the latest ubuntu..deb or win.zip, installers.. I would assume that they would want master to be the "stable" ie tag-1.3. == latest-stable == master If changes are pushed to master in - which is what we all want as dev's, the the distributors will be rebuilding every day... This dilemma I know is from the flightgear.org, the flightsim project.. which is why that thought is very much in my mind.. the issue there with master vs tag vs dev is huge.. so at least all the devs know that next is fun and not dangerous.. kinda.. > > Peter's next+master workflow is what the Linux kernel uses. It kind of > mirrors master+stable branches in other projects. > > didnt know that.. but it does that use odd for dev and even for release .. is that a numbering schema.. ? > One alternative workflow is called git-flow, which is outlined here: > http://nvie.com/posts/a-**successful-git-branching-**model/<http://nvie.com/posts/a-successful-git-branching-model/> > > One of the best ways to develop is using a continuous integration model. > In this model, each commit to "master" is compiled and run against a series > of tests, to determine if the project is viable. > > Travis CI offers free continuous compiling/integration for open source > projects. It even integrates with github: > https://travis-ci.org/ > > Whaw Jason.. snap.. ;-) The travis job is here..im my branch atmo And there is no make test... But indeed we can build against it certainly.. means dimitri can now with an ipad, do a marge and make a tag and release.. from somewhere on something.. === versioning == About revision Nos'' The problem is that the "current version" is hidden way in config.. What would be really helpful is to have a file "./version" with the release eg 7.8.9 This means that a remote system can directly check that "file" and deal with things.. Looking here at making release automatic builds.. ie a debian package, or windows install with nsis etc == Travis == Have the travis kinda working of "daffodil" which is my github fork.. https://github.com/daffodil/doxygen the config is here https://github.com/daffodil/doxygen/blob/master/.travis.yml Problem To make travis work as a link.. The README is now a README.md with markdown This is richer and better..... Merge request is here https://github.com/doxygen/doxygen/pull/1 Travis is real cool cos the binaries can be built there.. Anyway.. this is fun.. ALSO =============== BUGS =============== I'll be frank, I hate bugzilla, its a pain to even want to find a bug.. So can we enable the Issues in GitHub please, and the lovely thing for github is it integrates well.. There's a scipt and stuff here.. So need to bind the bugs to the source which is what git hub does well, eg match bug against patch http://stackoverflow.com/questions/7281304/migrate-bugzilla-issues-to-github-issue-tracker regards pete |
|
From: Oleg B. <og...@gm...> - 2013-05-21 06:01:56
|
Hi, One of the challenges with git is that is flexible and allows for many > work flows. There isn't one "right way", but there are some common > workflows. > Just a note for former SVN users, who learn git. :) Branches and repos in git are symmetric, there is no special branch like "trunk" (git may set up some names as default for actions in its config, like 'master', but even this is (I think always) reconfigurable). You can push any branch from local repo to any branch in remote repo (and vice versa). And because repos are symmetric I sometimes even find myself pushing (fetching) from one local repo to another, when I want to avoid central storage. > > The most common workflow that I have seen is as follows: > * most or all development happens on the master branch > * each new feature gets it's own branch, which is merged or rebased with > the master branch when it's mostly complete and doesn't break the build. > * releases are cut as tags from master or from a version branch or > stable branch(i.e. potential branches: master, stable, 1.2.x, 1.3.x, > tags: 1.2.1, 1.2.2, 1.3.1) > This is what I had in mind as well. I have not tried github "pull requests" yet, but it seems to me that most developers in open source project have their own repo mirrors and main developer (+some dedicated) pull the changes into the main repo. In this sense most fixes have their own repos.. Maybe it is reasonable to try separate branches for a set of features like 'C++ parser', 'python parser' where Dimitri (or dedicated user) pulls new functionality without much review, so we can see it and try it out together, and before release (or after thorough review) merges it all into master and then merges the master branch back to every functionality branch. Or maybe its just too complicated for a moderate size project.. Oleg |
|
From: Dimitri v. H. <di...@st...> - 2013-05-22 17:32:59
|
Hi Petr, On May 20, 2013, at 17:06 , Petr Prikryl <Pr...@sk...> wrote: >> [...] any tips are welcome ;-) > > I suggest to introduce the .gitignore file at the root level > with a directory that anyone can use for whatever. The reason > is that I would like to use some "private" subdirectory that > is near to doxygen's everything. > > Sure, I can make my own fork, my own .gitignore, and I can > secretly decide what the name of the directory is to be. > However, the pull request/merge would not be that easy in such case. > The goal is to keep the .gitignore public. Because of that, > the private subdirectory should be named publicly. > > It can be defined via prefix and the wildcard. I suggest > to put the following line to the .gitignore: > > __*/ > > i.e. two underscores, star, slash. This way, any directory > that starts with two underscores will be considered private. > > This way, developers will be free to create whatever private > subdirectory they like, wherever they like. > > The rule "the two-underscore prefix" is easy to explain. I just found this http://365git.tumblr.com/post/519016351/three-ways-of-excluding-files using the 3rd method (excludesfile in .gitconfig) you can add additional stuff to ignore. Seems like a better approach for private stuff. I'll use this to exclude my own private stuff, and have a proper .gitignore that I can commit. Regards, Dimitri |
|
From: Petr P. <Pr...@sk...> - 2013-05-23 07:10:19
|
For the non-private purpose, there probably still is the need for .gitignore files (at least related to compilation for Windows) to exclude the generated files (also the VERSION file) -- probably at the root level: bin/Debug/ bin/Debug64/ bin/Release/ bin/Release64/ VERSION There also should be winbuild/.gitignore file with at least the following: Debug/ Debug64/ Release/ Release64/ Doxygen.ncb Doxygen.suo *.user And there also should be src/.gitignore to exclude the files generated from lex sources. Dimitri wrote: > Petr Prikryl wrote: > > I suggest to introduce the .gitignore file [...] > > to use some "private" subdirectory [...] __*/ > > i.e. two underscores, star, slash. This way, any directory that > > starts with two underscores will be considered private. > > I just found this > http://365git.tumblr.com/post/519016351/three-ways-of-excluding-files > using the 3rd method (excludesfile in .gitconfig) you can add > additional stuff to ignore. Seems like a better approach for private > stuff. I agree this is better approach for private directories. I am going to use the 2nd metod (.git/info/excludes) for some reason. Still learning ;) Regards, Petr |
|
From: Peter M. <ped...@gm...> - 2013-05-22 20:52:21
|
> I just found this > http://365git.tumblr.com/post/519016351/three-ways-of-excluding-files > using the 3rd method (excludesfile in .gitconfig) you can add additional > stuff to ignore. Seems like a better approach for private stuff. > > I'll use this to exclude my own private stuff, > and have a proper .gitignore that I can commit. > > umm.. seems a strange way to me. Why not use your own local private branch.. this way u can keep master in sync with head and then merge into you local "private" branch Pete |
|
From: Oleg B. <og...@gm...> - 2013-05-22 21:13:22
|
> I'll use this to exclude my own private stuff, >> and have a proper .gitignore that I can commit. >> >> umm.. seems a strange way to me. > Why not use your own local private branch.. > > this way u can keep master in sync with head > and then merge into you local "private" branch > Then you have to switch to master branch before every commit or cherry-pick your commits later.. Local 'ignore conf' is less troubling. Oleg > > Pete > > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > Doxygen-develop mailing list > Dox...@li... > https://lists.sourceforge.net/lists/listinfo/doxygen-develop > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X