doxygen-develop — List for discussing new features, submitting patches, etc.

[Doxygen-develop] Doxygen linkifies arguments names

[Aleksandr P. <pa...@ok...>]

Hi.
I think that behavior described in subj. is incorrect, e.g. argument
name could be the same as a typedef name
https://bugzilla.gnome.org/show_bug.cgi?id=640156

The problem is in line 1660 of src/memberdef.cpp file:
linkifyText() function is called for the whole argsString() thus
arguments names could be linkified.

I have created patch (see attachment) which replaces linkifyText() call
at line 1660 with loop which calls linkifyText() for arguments types and
default values and ol.writeString() for arguments names. This solution
looks like dirty hack, but I have no idea how this problem could be
solved in another way.

Is it really problem or expected behavior?
Could you take a look at my patch?
-- 
Aleksandr Platonov

Re: [Doxygen-develop] CMake

[Robert D. <rcd...@gm...>]

On Thu, Jun 6, 2013 at 4:03 PM, Robert Dailey <rcd...@gm...> wrote:
> Starting a new discussion thread here in the dev mailing list for
> CMake support. I'll be working on this over on my github fork:
> https://github.com/rcdailey/doxygen
>
> I'll be spending my spare time on this so please forgive any slow progress :)

Concerning third party dependencies that you do not build yourself as
part of your make command, would you be able to maintain your own
binaries for these in a repository?

I already have a CMake framework that I can drop into doxygen and use.
To be the most platform agnostic, I have set it up to download
archives of precompiled binaries for third party libraries from an
FTP/HTTP/Windows file share of your choosing (configurable in CMake
cache). Basically for every platform or toolchain you plan to build
doxygen on or with, you will need to have include files + binaries in
an archive. Those will sit in a repository and the CMake scripts will
download them, extract them, and automatically setup include
directories and dependencies for you.

There are a couple of benefits to having this approach:
1. No need to search for these libraries on the system. The CMake
scripts will always be able to guarantee that they are on the  system
since it will be downloading them from a repository you maintain.
2. Easier for new developers to just pick up the code and start
building, since they do not have to spend time building libraries.
3. Windows doesn't have an apt-get (unless you use cygwin, which is
just another dependency to worry about) mechanism, so this makes up
for that and makes it super easy to get a build started on Windows.

The downside, of course, is that this can become a maintenance problem
if you have a ton of libraries and/or platforms or toolchains to
support.

Let me know how you want to approach this, as it will deeply impact
the work. Personally I suggest we take this approach, assuming you can
setup an FTP/HTTP server somewhere to pull down the archives. I will
also post this in the dev mailing list, as I have created a dedicated
thread there for CMake discussion. Join me there!

Re: [Doxygen-develop] Problem with default values

[Robert D. <rcd...@gm...>]

On Thu, Jun 6, 2013 at 3:39 PM, Dimitri van Heesch <do...@gm...> wrote:
> Hi Robert,
>
> Some things to carry over:
> - options --with-doxywizard, --with-doxyapp, --with-doxysearch --with-sqlite3, --with-libclang, --with-libclang-static
> - checking for flex, bison, perl & python (required for building), bison has to be version 1.35 or higher
> - checking for Qt4 (optional needed for --with-doxywizard)
> - checking for Xapian (optional needed for --with-doxysearch)
> - checking for Sqlite3 (optional needed for --with-sqlite3)
> - checking for libclang (optional needed for --with-libclang)
> (for the current checks and options see the configure script)
> - linking specific libclang/llvm libraries staticly (optional needed for --with-libclang-static)
> - I build ce_parse.cpp and ce_parse.h from constexp.y with proper dependency tracking
> - I create a bunch of .cpp files from .l files (flex), each using their own -p option.
> - I create *_js.h from a bunch of .js files via a sed command (same for other 'resource' files)
> - I post-process the the output of flex with a perl filter before writing it to disk
> - I create configoption.cpp from config.xml via a Python script
> (most of the 'special stuff' can be found in src/libdoxygen.t and src/libdoxycfg.t, to tmake
> config files).
> - a src/settings.h is to be generate with USE_SQLITE3 and USE_LIBCLANG set depending
> on --with-sqlite3 and --with-libclang
> - a src/version.cpp should be generated with the version of doxygen (current stored in the
> configure file, but that could better be another file).

Concerning third party dependencies that you do not build yourself as
part of your make command, would you be able to maintain your own
binaries for these in a repository?

I already have a CMake framework that I can drop into doxygen and use.
To be the most platform agnostic, I have set it up to download
archives of precompiled binaries for third party libraries from an
FTP/HTTP/Windows file share of your choosing (configurable in CMake
cache). Basically for every platform or toolchain you plan to build
doxygen on or with, you will need to have include files + binaries in
an archive. Those will sit in a repository and the CMake scripts will
download them, extract them, and automatically setup include
directories and dependencies for you.

There are a couple of benefits to having this approach:
1. No need to search for these libraries on the system. The CMake
scripts will always be able to guarantee that they are on the  system
since it will be downloading them from a repository you maintain.
2. Easier for new developers to just pick up the code and start
building, since they do not have to spend time building libraries.
3. Windows doesn't have an apt-get (unless you use cygwin, which is
just another dependency to worry about) mechanism, so this makes up
for that and makes it super easy to get a build started on Windows.

The downside, of course, is that this can become a maintenance problem
if you have a ton of libraries and/or platforms or toolchains to
support.

Let me know how you want to approach this, as it will deeply impact
the work. Personally I suggest we take this approach, assuming you can
setup an FTP/HTTP server somewhere to pull down the archives. I will
also post this in the dev mailing list, as I have created a dedicated
thread there for CMake discussion. Join me there!

[Doxygen-develop] CMake

[Robert D. <rcd...@gm...>]

Starting a new discussion thread here in the dev mailing list for
CMake support. I'll be working on this over on my github fork:
https://github.com/rcdailey/doxygen

I'll be spending my spare time on this so please forgive any slow progress :)

Re: [Doxygen-develop] Problem with default values

[Dimitri v. H. <do...@gm...>]

On Jun 6, 2013, at 22:16 , Robert Dailey <rcd...@gm...> wrote:
Hi Robert,

> On Thu, Jun 6, 2013 at 12:24 PM, Dimitri van Heesch <do...@gm...> wrote:
>> Hi Robert,
>> 
>> On Jun 6, 2013, at 18:33 , Robert Dailey <rcd...@gm...> wrote:
>> 
>>> +1 to CMake. I'm pretty good with CMake so I'm willing to help produce
>>> the build system if there is interest.
>> 
>> There are quite some custom steps in doxygen's build, but you can migrate the build to CMake
>> I'm interested.
> 
> (Sending again to mailing list this time, sorry for the dupe)
> 
> Ok I'll get started on it tonight.
> 
> If you don't mind, to help move me along quicker, can you please
> describe some important points about the build system that need to be
> carried over? Specifically the code generator, how it needs to run,
> what source files it generates, etc. Just really anything that comes
> to mind, no matter how trivial, please list it here so I don't miss it
> :)

Some things to carry over:
- options --with-doxywizard, --with-doxyapp, --with-doxysearch --with-sqlite3, --with-libclang, --with-libclang-static
- checking for flex, bison, perl & python (required for building), bison has to be version 1.35 or higher
- checking for Qt4 (optional needed for --with-doxywizard)
- checking for Xapian (optional needed for --with-doxysearch)
- checking for Sqlite3 (optional needed for --with-sqlite3)
- checking for libclang (optional needed for --with-libclang)
(for the current checks and options see the configure script)
- linking specific libclang/llvm libraries staticly (optional needed for --with-libclang-static)
- I build ce_parse.cpp and ce_parse.h from constexp.y with proper dependency tracking
- I create a bunch of .cpp files from .l files (flex), each using their own -p option.
- I create *_js.h from a bunch of .js files via a sed command (same for other 'resource' files)
- I post-process the the output of flex with a perl filter before writing it to disk
- I create configoption.cpp from config.xml via a Python script
(most of the 'special stuff' can be found in src/libdoxygen.t and src/libdoxycfg.t, to tmake
config files).
- a src/settings.h is to be generate with USE_SQLITE3 and USE_LIBCLANG set depending 
on --with-sqlite3 and --with-libclang
- a src/version.cpp should be generated with the version of doxygen (current stored in the
configure file, but that could better be another file).

Regards,
  Dimitri

Re: [Doxygen-develop] Problem with default values

[Robert D. <rcd...@gm...>]

On Thu, Jun 6, 2013 at 12:24 PM, Dimitri van Heesch <do...@gm...> wrote:
> Hi Robert,
>
> On Jun 6, 2013, at 18:33 , Robert Dailey <rcd...@gm...> wrote:
>
>> +1 to CMake. I'm pretty good with CMake so I'm willing to help produce
>> the build system if there is interest.
>
> There are quite some custom steps in doxygen's build, but you can migrate the build to CMake
> I'm interested.

(Sending again to mailing list this time, sorry for the dupe)

Ok I'll get started on it tonight.

If you don't mind, to help move me along quicker, can you please
describe some important points about the build system that need to be
carried over? Specifically the code generator, how it needs to run,
what source files it generates, etc. Just really anything that comes
to mind, no matter how trivial, please list it here so I don't miss it
:)

Thanks!!

Re: [Doxygen-develop] Problem with default values

[Dimitri v. H. <do...@gm...>]

Hi Robert,

On Jun 6, 2013, at 18:33 , Robert Dailey <rcd...@gm...> wrote:

> +1 to CMake. I'm pretty good with CMake so I'm willing to help produce
> the build system if there is interest.

There are quite some custom steps in doxygen's build, but you can migrate the build to CMake
I'm interested. 

> 2013 at 6:46 PM, Philipp Moeller
> <phi...@ge...> wrote:
>> Dimitri van Heesch <do...@gm...> writes:
>> 
>>> On Jun 3, 2013, at 22:45 , Philipp Moeller <phi...@ge...> wrote:
>>>> 
>>>> NB: To add a config variable you need to add it to the config.xml file
>>>> and not to the configoptions.cpp file. Don't forget to rerun
>>>> configgen.py. It is really unfortunate that the file is commited and not
>>>> generated during the build process.
>>> 
>>> This is limitation of the Windows build. When using ./configure & make on
>>> Linux/MacOSX/Cygwin there is a build rule to trigger a regeneration whenever
>>> config.xml changes.
>> 
>> This is odd. It is possible to have MSBuild Tasks run an external
>> executable depending on some resource and some platform-independent
>> build tools also support generating that kind of solution file. Maybe
>> its time to switch to CMake?

It is not that it is not possible. It just hasn't been implemented. 
Note that I do almost no development on Windows myself, I only build and test 
the Windows binaries just before a release, so for me is not much of an issue.

Regards,
  Dimitri

Re: [Doxygen-develop] Problem with default values

[Robert D. <rcd...@gm...>]

+1 to CMake. I'm pretty good with CMake so I'm willing to help produce
the build system if there is interest.

On Wed, Jun 5, 2013 at 6:46 PM, Philipp Moeller
<phi...@ge...> wrote:
> Dimitri van Heesch <do...@gm...> writes:
>
>> On Jun 3, 2013, at 22:45 , Philipp Moeller <phi...@ge...> wrote:
>>>
>>> NB: To add a config variable you need to add it to the config.xml file
>>> and not to the configoptions.cpp file. Don't forget to rerun
>>> configgen.py. It is really unfortunate that the file is commited and not
>>> generated during the build process.
>>
>> This is limitation of the Windows build. When using ./configure & make on
>> Linux/MacOSX/Cygwin there is a build rule to trigger a regeneration whenever
>> config.xml changes.
>
> This is odd. It is possible to have MSBuild Tasks run an external
> executable depending on some resource and some platform-independent
> build tools also support generating that kind of solution file. Maybe
> its time to switch to CMake?

Re: [Doxygen-develop] Problem with default values

[Philipp M. <phi...@ge...>]

Dimitri van Heesch <do...@gm...> writes:

> On Jun 3, 2013, at 22:45 , Philipp Moeller <phi...@ge...> wrote:
>> 
>> NB: To add a config variable you need to add it to the config.xml file
>> and not to the configoptions.cpp file. Don't forget to rerun
>> configgen.py. It is really unfortunate that the file is commited and not
>> generated during the build process.
>
> This is limitation of the Windows build. When using ./configure & make on
> Linux/MacOSX/Cygwin there is a build rule to trigger a regeneration whenever
> config.xml changes.

This is odd. It is possible to have MSBuild Tasks run an external
executable depending on some resource and some platform-independent
build tools also support generating that kind of solution file. Maybe
its time to switch to CMake?

Re: [Doxygen-develop] Problem with default values

[Dimitri v. H. <do...@gm...>]

On Jun 3, 2013, at 22:45 , Philipp Moeller <phi...@ge...> wrote:
> 
> NB: To add a config variable you need to add it to the config.xml file
> and not to the configoptions.cpp file. Don't forget to rerun
> configgen.py. It is really unfortunate that the file is commited and not
> generated during the build process.

This is limitation of the Windows build. When using ./configure & make on
Linux/MacOSX/Cygwin there is a build rule to trigger a regeneration whenever
config.xml changes.

Regards,
  Dimitri

Re: [Doxygen-develop] #undef is ignored by Doxygen

[Aleksandr P. <pa...@ok...>]

On Mon, 2013-06-03 at 13:52 +0400, Aleksandr Platonov wrote:
> Hi.
> I found that #undef is ignored by Doxygen and opened Bug about this
> problem https://bugzilla.gnome.org/show_bug.cgi?id=694147
> But got no response for about 3 month. The problem is still exist in
> latest Doxygen. Could anybody look at this?
> 
It seems that patch should be the following:

diff --git a/src/pre.l b/src/pre.l
index 4c017da..6f05d91 100644
--- a/src/pre.l
+++ b/src/pre.l
@@ -233,6 +233,7 @@ class DefineManager
     {
       Define *d = m_contextDefines.find(name);
       //printf("isDefined(%s)=%p\n",name,d);
+      if (d && d->undef) d=0;
       return d;
     }
     /** Returns a reference to the defines found in the current
context. */

-- 
Aleksandr Platonov

Re: [Doxygen-develop] Problem with default values

[Philipp M. <phi...@ge...>]

Robert Dailey <rcd...@gm...> writes:

> Hi,
>
> I'm adding some new config options to Doxygen. Here is my code:
>
>
>   cs = cfg->addString(
>                  "WARN_STRING",
>                  "The string that is prefixed to each warning that
> will be printed."
>                 );
>   cs->setDefaultValue("Warning: ");
>
> Notice I have a trailing space after the colon for the default value.
> I noticed that after ConfigString::substEnvVars() is called, this
> space is removed. I'd like to be able to keep the spaces in the
> default value. How can I do this?

The responsible code for stripping is in line 2843 in config.cpp. The
whole substitution process seems a little bit awkward and fixing it
might be more involved.

NB: To add a config variable you need to add it to the config.xml file
and not to the configoptions.cpp file. Don't forget to rerun
configgen.py. It is really unfortunate that the file is commited and not
generated during the build process.

Re: [Doxygen-develop] Problem with default values

[Robert D. <rcd...@gm...>]

On Mon, Jun 3, 2013 at 4:01 PM, Robert Dailey <rcd...@gm...> wrote:
> Thanks for the information guys, I'm still learning the code base. I
> submitted a patch here to add some new config variables:
> https://bugzilla.gnome.org/show_bug.cgi?id=701550
>
> However, I need to re-post the patch with changes to the XML file
> instead. Will the VS9 project re-generate the file for me? Please let
> me know what else I'm doing wrong in the patch so I can correct it.
> Thanks again guys.

Ok, I took a lucky guess on generating the file. I ran:

configgen.py config.xml > configoptions.cpp

I notice however that the description string isn't manually
word-wrapped like the other options. Here is my new XML code:

    <option type='string' id='WARN_STRING' format='string' docs='
The string that is prefixed to each warning that will be printed. A space
is automatically placed between the prefix and the message that follows.
' defval='Warning:'/>
    <option type='string' id='ERROR_STRING' format='string' docs='
The string that is prefixed to each error that will be printed. A space
is automatically placed between the prefix and the message that follows.
' defval='Error:'/>

And the code output is:

  //----
  cs = cfg->addString(
                 "WARN_STRING",
                 "The string that is prefixed to each warning that
will be printed. A space is automatically placed between the prefix
and the message that follows."
                );
  cs->setDefaultValue("Warning:");
  //----
  cs = cfg->addString(
                 "ERROR_STRING",
                 "The string that is prefixed to each error that will
be printed. A space is automatically placed between the prefix and the
message that follows."
                );
  cs->setDefaultValue("Error:");

Since I'm sending plain text email, the mail server probably word
wraps my code snippets so you won't be able to see the effects. But
notice no literal '\n' in the string...

Re: [Doxygen-develop] Problem with default values

[Robert D. <rcd...@gm...>]

Thanks for the information guys, I'm still learning the code base. I
submitted a patch here to add some new config variables:
https://bugzilla.gnome.org/show_bug.cgi?id=701550

However, I need to re-post the patch with changes to the XML file
instead. Will the VS9 project re-generate the file for me? Please let
me know what else I'm doing wrong in the patch so I can correct it.
Thanks again guys.

On Mon, Jun 3, 2013 at 3:51 PM, Doxygen <do...@gm...> wrote:
> Hi Robert,
>
> On 3 jun. 2013, at 22:33, Robert Dailey <rcd...@gm...> wrote:
>
>> Hi,
>>
>> I'm adding some new config options to Doxygen. Here is my code:
>>
>>
>>  cs = cfg->addString(
>>                 "WARN_STRING",
>>                 "The string that is prefixed to each warning that
>> will be printed."
>>                );
>>  cs->setDefaultValue("Warning: ");
>
> Please add new options to config.xml not to configoptions.cpp which is generated from it.
>
>>
>> Notice I have a trailing space after the colon for the default value.
>> I noticed that after ConfigString::substEnvVars() is called, this
>> space is removed. I'd like to be able to keep the spaces in the
>> default value. How can I do this?
>
> I guess we should fix substEnvVars not to strip the space...
>
> Regards,
>   Dimitri
>

Re: [Doxygen-develop] Problem with default values

[Doxygen <do...@gm...>]

Hi Robert,

On 3 jun. 2013, at 22:33, Robert Dailey <rcd...@gm...> wrote:

> Hi,
> 
> I'm adding some new config options to Doxygen. Here is my code:
> 
> 
>  cs = cfg->addString(
>                 "WARN_STRING",
>                 "The string that is prefixed to each warning that
> will be printed."
>                );
>  cs->setDefaultValue("Warning: ");

Please add new options to config.xml not to configoptions.cpp which is generated from it.

> 
> Notice I have a trailing space after the colon for the default value.
> I noticed that after ConfigString::substEnvVars() is called, this
> space is removed. I'd like to be able to keep the spaces in the
> default value. How can I do this?

I guess we should fix substEnvVars not to strip the space...

Regards,
  Dimitri

[Doxygen-develop] Problem with default values

[Robert D. <rcd...@gm...>]

Hi,

I'm adding some new config options to Doxygen. Here is my code:


  cs = cfg->addString(
                 "WARN_STRING",
                 "The string that is prefixed to each warning that
will be printed."
                );
  cs->setDefaultValue("Warning: ");

Notice I have a trailing space after the colon for the default value.
I noticed that after ConfigString::substEnvVars() is called, this
space is removed. I'd like to be able to keep the spaces in the
default value. How can I do this?

[Doxygen-develop] #undef is ignored by Doxygen

[Aleksandr P. <pa...@ok...>]

Hi.
I found that #undef is ignored by Doxygen and opened Bug about this
problem https://bugzilla.gnome.org/show_bug.cgi?id=694147
But got no response for about 3 month. The problem is still exist in
latest Doxygen. Could anybody look at this?

-- 
Aleksandr Platonov

Re: [Doxygen-develop] [PATCH] fix regression on file reference page

[Dimitri v. H. <di...@st...>]

Hi Michael,

On May 29, 2013, at 16:57 , Michael Stahl <ms...@re...> wrote:

> 
> sadly there was a stupid copy/paste error in my UNO IDL patch, causing
> namespaces to be listed twice on the file reference pages, which is
> fixed by the attached patch; sorry about that.

Thanks, I've pushed the fix to GitHub.

Regards,
  Dimitri

[Doxygen-develop] [PATCH] fix regression on file reference page

[Michael S. <ms...@re...>]

sadly there was a stupid copy/paste error in my UNO IDL patch, causing
namespaces to be listed twice on the file reference pages, which is
fixed by the attached patch; sorry about that.

regards,
 michael

[Doxygen-develop] .gitignore files for non-private files and directories

[Petr P. <Pr...@sk...>]

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

Re: [Doxygen-develop] Doxygen's code repository has moved to GitHub

[Oleg B. <og...@gm...>]

> 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
>
>

Re: [Doxygen-develop] Doxygen's code repository has moved to GitHub

[Peter M. <ped...@gm...>]

> 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

Re: [Doxygen-develop] Doxygen's code repository has moved to GitHub

[Dimitri v. H. <di...@st...>]

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

Re: [Doxygen-develop] Doxygen's code repository has moved to GitHub

[Petr P. <Pr...@sk...>]

> 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

Re: [Doxygen-develop] [Doxygen-users] Doxygen's code repository has moved to GitHub

[Oleg B. <og...@gm...>]

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