Discussion:
[Inkscape-devel] Inkscape 0.47 Development Plans
Bryce Harrington
2008-03-14 05:54:00 UTC
Permalink
Hi all,

With Inkscape 0.46 wrapping up, it's time to look forward to our next
release, 0.47, and our plans for its development.

When we started Inkscape, we began with a codebase with lots of
potential but with some architectural limitations that we've never quite
resolved. Inkscape has grown rapidly, especially thanks to Google's
Summer of Code program. Unfortunately, while we've gained a lot of new
features, it hasn't addressed the underlying issues - and in some cases
has exposed new problems.

Inkscape's also been extremely successful at gaining a lot of
contributors, yet this comes with a price: Stylistic differences,
accidental code duplication, unfinished code, obsoleted code, etc.

What will the codebase cleanup work entail? The work will range from
straightforward "grunt" work like making some simple code changes to all
files in the codebase, to meatier work like abstracting widely used code
into a more concise and powerful algorithm, to advanced work such as
extracting distinct code into independent code packages.

To boil this down into five high level objectives:

0. Complete some of the big architectural refactoring efforts
1. Reduce source code line count
2. Break useful code out into stand-alone libraries
3. Increase code stylistic consistency
4. Make the codebase more convenient to code in

Now, architectural reworkings can often risk incur massive breakages
since fundamental pieces of the code are being changed. In order to
minimize this, I'd like to suggest the following principles:

* Always keep the tree buildable
* Do major refactorings in small steps
* Hold code review parties with 2-3 others to brainstorm
* Drop copied-in codebases in favor of external dependencies
* Make sure every function you touch has some doxygen comments

Further, this kind of work can go on indefinitely without a clear
stopping point, so I think for this release we should use a schedule
with a date-based stopping point. This will help everyone know how they
should time their work.

Mar 10 Release 0.46. 0.47 Refactoring / Cleanup work begins
Apr
May
Jun
Jul 1 Completion of refactoring. Focus on Bug Fixing begins.
Open 0.48 development tree early, for GSoC work.
Aug Put out 0.47-pre releases.
Sep Release 0.47.

For reference, here are some key GSoC dates:

May 26 GSoC work begins.
Jul 14 GSoC midterm. First delivery of GSoC code
Aug 18 GSoC work ends.

This schedule permits us to focus exclusively on refactoring for several
months, with a due date of July 1st to complete it. It uses a very
early branch point, where we'll split into a stable branch for doing bug
fix and release work, and a development branch for the GSoC students to
use and for folks to continue right on with refactoring projects if they
wish.

Bryce
Bryce Harrington
2008-03-14 06:34:53 UTC
Permalink
Forgot to mention, I've also updated the Roadmap, and listed some more
specific tasks:

http://wiki.inkscape.org/wiki/index.php/Roadmap
Post by Bryce Harrington
Hi all,
With Inkscape 0.46 wrapping up, it's time to look forward to our next
release, 0.47, and our plans for its development.
When we started Inkscape, we began with a codebase with lots of
potential but with some architectural limitations that we've never quite
resolved. Inkscape has grown rapidly, especially thanks to Google's
Summer of Code program. Unfortunately, while we've gained a lot of new
features, it hasn't addressed the underlying issues - and in some cases
has exposed new problems.
Inkscape's also been extremely successful at gaining a lot of
contributors, yet this comes with a price: Stylistic differences,
accidental code duplication, unfinished code, obsoleted code, etc.
What will the codebase cleanup work entail? The work will range from
straightforward "grunt" work like making some simple code changes to all
files in the codebase, to meatier work like abstracting widely used code
into a more concise and powerful algorithm, to advanced work such as
extracting distinct code into independent code packages.
0. Complete some of the big architectural refactoring efforts
1. Reduce source code line count
2. Break useful code out into stand-alone libraries
3. Increase code stylistic consistency
4. Make the codebase more convenient to code in
Now, architectural reworkings can often risk incur massive breakages
since fundamental pieces of the code are being changed. In order to
* Always keep the tree buildable
* Do major refactorings in small steps
* Hold code review parties with 2-3 others to brainstorm
* Drop copied-in codebases in favor of external dependencies
* Make sure every function you touch has some doxygen comments
Further, this kind of work can go on indefinitely without a clear
stopping point, so I think for this release we should use a schedule
with a date-based stopping point. This will help everyone know how they
should time their work.
Mar 10 Release 0.46. 0.47 Refactoring / Cleanup work begins
Apr
May
Jun
Jul 1 Completion of refactoring. Focus on Bug Fixing begins.
Open 0.48 development tree early, for GSoC work.
Aug Put out 0.47-pre releases.
Sep Release 0.47.
May 26 GSoC work begins.
Jul 14 GSoC midterm. First delivery of GSoC code
Aug 18 GSoC work ends.
This schedule permits us to focus exclusively on refactoring for several
months, with a due date of July 1st to complete it. It uses a very
early branch point, where we'll split into a stable branch for doing bug
fix and release work, and a development branch for the GSoC students to
use and for folks to continue right on with refactoring projects if they
wish.
Bryce
Maximilian Albert
2008-03-14 12:57:49 UTC
Permalink
Post by Bryce Harrington
Forgot to mention, I've also updated the Roadmap, and listed some more
http://wiki.inkscape.org/wiki/index.php/Roadmap
Regarding the C++-ification of SPObjects, what is the best way to
proceed? As I understand it, it is not really possible (or feasible) to
mix GObjects and true C++ objects so I suppose that we would need to
first switch "under the hood" and then get rid of the GObject framework
in one go, right?

So for each SPObject a corresponding C++ class needs to be created which
encapsulates its functionality, and all the SPObject "methods" would be
changed to only call the corresponding ones of the new class (as seems
to already be the case in sp-item-group.cpp). Is that correct or am I
getting something completely wrong here? Should we keep a list on the
wiki for which SPObjects this conversion has already be done so that we
can keep track of the progress?

Max
MenTaLguY
2008-03-15 20:58:19 UTC
Permalink
Post by Maximilian Albert
So for each SPObject a corresponding C++ class needs to be created which
encapsulates its functionality, and all the SPObject "methods" would be
changed to only call the corresponding ones of the new class (as seems
to already be the case in sp-item-group.cpp). Is that correct or am I
getting something completely wrong here? Should we keep a list on the
wiki for which SPObjects this conversion has already be done so that we
can keep track of the progress?
I'm not happy with the approach that was taken with CGroup -- I think
it's an unmaintainable mess, and we'd be unlikely to ever finish the
migration if we went that route.

My preferred approach would be to replace GObject with NRObject in the
SPObject hierarchy, removing the inter-SPObject refcounting (which would
create unbreakable GC cycles) and explicit member initialization (no
longer needed, as NRObject calls the C++ constructor/destructors). At
that point we can start using all C++ features directly in the existing
SPObject classes.

It's a big hurdle to get over initially, but it's one shot, and once we
do it we can start improving the design and adopting native C++ features
organically and incrementally.

-mental
MenTaLguY
2008-03-15 22:01:19 UTC
Permalink
Post by MenTaLguY
My preferred approach would be to replace GObject with NRObject in the
SPObject hierarchy, removing the inter-SPObject refcounting (which would
create unbreakable GC cycles) and explicit member initialization (no
longer needed, as NRObject calls the C++ constructor/destructors). At
that point we can start using all C++ features directly in the existing
SPObject classes.
Actually, I think it may be best if I move the GC stuff into e.g. a
distinct NRGCObject subclass, so that we don't have to do the GC
migration things at the same time as everything else.

-mental
Chris Lilley
2008-03-14 13:40:45 UTC
Permalink
On Friday, March 14, 2008, 7:34:53 AM, Bryce wrote:

BH> Forgot to mention, I've also updated the Roadmap, and listed some more
BH> specific tasks:

BH> http://wiki.inkscape.org/wiki/index.php/Roadmap

In milestones 15 and 16, which seem to be focussed on mobile, multipage is listed.

Does that date from when the SVG WG was trying to use the same page construct for actual printed pages and also for animation scenes? (We no longer do this). SVG Tiny 1.2 does not have multipage.

However, it does have a bunch of other features that would be interesting to author - video, audio, discard, the animation element, and so forth.

Is anyone else interested in working on a list of SVG Tiny 1.2 features that go beyond SVG 1.1, from an authoring perspective, and discussing what authoring challenges each feature might present?

Same question, but this time for authoring SVG Print documents. In case the answer to my first question was "no, it means multiple pages like in SVG Print".
--
Chris Lilley mailto:***@w3.org
Interaction Domain Leader
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG
Bryce Harrington
2008-03-14 18:05:25 UTC
Permalink
Post by Chris Lilley
BH> Forgot to mention, I've also updated the Roadmap, and listed some more
BH> http://wiki.inkscape.org/wiki/index.php/Roadmap
In milestones 15 and 16, which seem to be focussed on mobile, multipage is listed.
Does that date from when the SVG WG was trying to use the same page construct for actual printed pages and also for animation scenes? (We no longer do this). SVG Tiny 1.2 does not have multipage.
No, it's just an oft-requested feature, and coincidental that it got
listed there.

Note that while our milestones "declare" a focus, in reality much of
Inkscape development is parallel, and strongly driven by the developer
interest. So we may say that Foo feature is scheduled for 0.49, but if
no one is interested in working on it, it might get pushed back to ever
later releases (which is what has happened with both animation and
multipage.) On the other hand, other features which are of interest,
often get done earlier.

So, it's best to think of the Roadmap not as a work plan, but more of a
weather forecast.

Bryce
Jon A. Cruz
2008-03-14 06:53:00 UTC
Permalink
Post by Bryce Harrington
Now, architectural reworkings can often risk incur massive breakages
since fundamental pieces of the code are being changed. In order to
* Always keep the tree buildable
* Do major refactorings in small steps
* Hold code review parties with 2-3 others to brainstorm
* Drop copied-in codebases in favor of external dependencies
* Make sure every function you touch has some doxygen comments
I think you missed one key point.

We need to get the unit test passing and updated.

Although some fails are not too hard to fix, but there are a few that
are probably critical. I recall that at least one is due to one of
our core string-enum-string round trips is failing. For that one we
might need to change a core assumption and approach.

I think that getting them working and keeping them working is
probably only second to "Always keep the tree buildable". If we can
have unit tests working and added to, then most of the other problems
can be reduced.

One other way to describe this is...

Before we start climbing up the front of the building to start
tearing down the facade, let's make sure we have a scaffolding up and
bolted solidly together instead of just leaning out from the window
ledges.

:-)
Maximilian Albert
2008-03-14 12:23:29 UTC
Permalink
Post by Jon A. Cruz
We need to get the unit test passing and updated.
Is there an overview of the test framework available somewhere? How does
it work? What is already there, what needs to be updated or newly
implemented and how can this be done? Sorry if these are dumb questions
(I couldn't find anything on the wiki) but apparently I haven't yet got
in touch with the testing stuff but would be interested in having a look
at it (if only to be able to have it in mind during future coding).

Max
Bryce Harrington
2008-03-14 18:21:34 UTC
Permalink
Post by Maximilian Albert
Post by Jon A. Cruz
We need to get the unit test passing and updated.
Is there an overview of the test framework available somewhere? How does
it work? What is already there, what needs to be updated or newly
implemented and how can this be done? Sorry if these are dumb questions
(I couldn't find anything on the wiki) but apparently I haven't yet got
in touch with the testing stuff but would be interested in having a look
at it (if only to be able to have it in mind during future coding).
There isn't an overview in Wiki, but you can see the code itself in
inkscape/cxxtest, which includes a simple user's guide in the README.
You can also see examples in inkscape/src/round-test.h,
extract-uri-test.h, etc.

Note there is also a src/utest/, which is used by attributes-test.h and
style-test.cpp. It seems to me that it's redundant to have two
different unit test systems in the code. cxxtest seems to be more
widely used; perhaps the tests currently using utest should be converted
to cxxtest, and utest dropped.

It would also be good to create a Wiki page about the test framework
(with a pointer to cxxtest's README for details) in case others go
looking for it. Maximilian, would you mind creating this?

Bryce
Bryce Harrington
2008-03-14 18:22:28 UTC
Permalink
Post by Jon A. Cruz
We need to get the unit test passing and updated.
Agreed; I've added this:
http://wiki.inkscape.org/wiki/index.php/0.47_Refactoring_Plan

Bryce
MenTaLguY
2008-03-15 20:49:03 UTC
Permalink
Post by Jon A. Cruz
We need to get the unit test passing and updated.
We also need to break up dependencies and stub/mock things as needed so
that individual test suites don't take 45 minutes to build.

As long as new test runs take as long as they currently do, I don't
think anyone's going to be seriously using the unit tests for anything.

-mental
j***@joncruz.org
2008-03-15 22:05:35 UTC
Permalink
Post by MenTaLguY
Post by Jon A. Cruz
We need to get the unit test passing and updated.
We also need to break up dependencies and stub/mock things as needed so
that individual test suites don't take 45 minutes to build.
As long as new test runs take as long as they currently do, I don't
think anyone's going to be seriously using the unit tests for anything.
Sounds like there is some debugging to do on the process. I don't see anything
near that on my system.

If I go into the src directory, ensure my inkscape compile is up to date, then
fire off a check, it goes very quickly:

real 0m42.900s
user 0m34.698s
sys 0m3.588s

So I'm seeing 43 seconds to build and execute the base unit tests, but you're
seeing 45 minutes. Something is seriously different.

Perhaps we need to just collect this on a "Unit Test Pain" page so we can fix it
for people seeing bad behavior.
MenTaLguY
2008-03-15 22:28:59 UTC
Permalink
Post by j***@joncruz.org
Sounds like there is some debugging to do on the process. I don't see anything
near that on my system.
If I go into the src directory, ensure my inkscape compile is up to date, then
real 0m42.900s
user 0m34.698s
sys 0m3.588s
So I'm seeing 43 seconds to build and execute the base unit tests, but you're
seeing 45 minutes. Something is seriously different.
It's been a while since I've looked at the tests -- it sounds like this
problem may already be fixed?

-mental
jiho
2008-03-14 09:54:35 UTC
Permalink
Post by Bryce Harrington
[...]
Now, architectural reworkings can often risk incur massive breakages
since fundamental pieces of the code are being changed. In order to
* Always keep the tree buildable
* Do major refactorings in small steps
* Hold code review parties with 2-3 others to brainstorm
* Drop copied-in codebases in favor of external dependencies
* Make sure every function you touch has some doxygen comments
[...]
This schedule permits us to focus exclusively on refactoring for several
months, with a due date of July 1st to complete it. It uses a very
early branch point, where we'll split into a stable branch for doing bug
fix and release work, and a development branch for the GSoC students to
use and for folks to continue right on with refactoring projects if they
wish.
Since this supposes a lot of branching (for SoC, probably also for
many large scale changes because the tree still needs to be usable
during that time etc.) wouldn't it be a good time to change version
control system to something that eases branching and merging? Plus,
distributed version control would ease a model where changes are
reviewed by several people before they are committed to the main tree
(i.e. just pull the changes from other people's trees and allow
commits to the main tree only by the reviewers). The discussions on
the list about this are old and quite long and to summarize them in a
few words:
- everybody agreed that there are solutions superior to svn in all
point of views
- the contenders are git, mercurial and bazaar
- all of them are pretty equivalent in terms of basic functionality now
- compare to basic svn usage (update, status, diff, commit, log) all
of them should be close enough so that they don't demand much learning
by developers used to only svn
- in all of them it should be possible to hook a check mechanism after
each commit (which would probably prove very useful in the context of
re-factoring to check the changes for 'make check' passing or other
custom test suite)

Now for the specific benefits/problems associated which each one (I
know git a little, not the others, so please fill in the blanks and
correct my mistakes so that we can come up with a clear list to decide
from (or not ;) ):

-- GIT ----------------------------
Good
- very fast (but anything would be faster than svn anyway)
- allows to stash away local changes to fix a small issue. probably
useful when, in the middle of a large code change, one notices a local
bug which does not have anything to do with the change (not sure this
is git-only)
- ability to follow chunk of codes around, without relying on file
names. Probably useful from a refactoring point of view
- probably the fastest growing user base => many tools

Bad
- does not run too well on windows



-- HG -----------------------------
Good


Bad



-- BZR ----------------------------
Good
- already integrated in launchpad

Bad



JiHO
---
http://jo.irisson.free.fr/
Maximilian Albert
2008-03-14 12:03:25 UTC
Permalink
Post by jiho
Since this supposes a lot of branching (for SoC, probably also for
many large scale changes because the tree still needs to be usable
during that time etc.) wouldn't it be a good time to change version
control system to something that eases branching and merging?
Excellent you bring this up and thanks for the succinct summary of the
discussion so far. I wholeheartedly agree that especially for the
purposes of refactoring switching version control systems would prove
extremely valuable.

Of the three alternatives you mentioned I also know only git so I can't
make substantiated comments on which of them would be best for our
purposes. But from what I've seen I guess I'd be happy with any of them
(although of course I wouldn't be disappointed if it were git :)).

Max
Joel Holdsworth
2008-03-14 16:45:22 UTC
Permalink
I'm still a little uncertain about this. Git seems increasingly popular,
and very powerful, it just doesn't seem very obvious to use for new
users. SVN is great at the moment, because there's a great GUI client
for windows (TortoiseSVN), and quite a good one for linux (RapidSVN).
Having easy source control clients seems like an easy way to get people
involved. So I'm wondering: are there any good GUI clients for git,
mercurial or bazaar?
Post by Maximilian Albert
Post by jiho
Since this supposes a lot of branching (for SoC, probably also for
many large scale changes because the tree still needs to be usable
during that time etc.) wouldn't it be a good time to change version
control system to something that eases branching and merging?
Excellent you bring this up and thanks for the succinct summary of the
discussion so far. I wholeheartedly agree that especially for the
purposes of refactoring switching version control systems would prove
extremely valuable.
Of the three alternatives you mentioned I also know only git so I can't
make substantiated comments on which of them would be best for our
purposes. But from what I've seen I guess I'd be happy with any of them
(although of course I wouldn't be disappointed if it were git :)).
Max
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Inkscape-devel mailing list
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
jiho
2008-03-14 17:21:03 UTC
Permalink
Post by Joel Holdsworth
I'm still a little uncertain about this. Git seems increasingly popular,
and very powerful, it just doesn't seem very obvious to use for new
users. SVN is great at the moment, because there's a great GUI client
for windows (TortoiseSVN), and quite a good one for linux (RapidSVN).
Having easy source control clients seems like an easy way to get people
involved. So I'm wondering: are there any good GUI clients for git,
mercurial or bazaar?
you can see the previous message on forked thread about that ("DVCS
again"). TortoiseHG and TortoiseBZR exists, TortoiseGIT does not. I
don't know the status of the first two compared to TortoiseSVN. On
linux there are apparently many clients for all three systems (from
the look on the wiki's of each project) but it is difficult to assess
their quality from just screenshots. I have not seen any file browser
integration (i.e. tortoiseSVN like) for linux, which unfortunately
would probably be the most useful thing to have (I read some stuff
about nautilus plugins but never saw anything actually working). For
OS X there's shell integration and a bunch of clients for SVN, not
much for the rest. But most of them are not good enough to avoid the
command line altogether, so I personally don't even use one. There is
however integration with a nice text editor (textmate) for svn, git,
and mercurial. nothing I can see for bazaar.

I'm not sure how critical having a good GUI is to get new developers.
To compile Inkscape you eventually have to go to the command line and
type stuff so... I agree however that TortoiseSVN probably makes the
life of existing windows developers easier. So has anyone tested
TortoiseHG/BZR ?

JiHO
---
http://jo.irisson.free.fr/
J***@ewi.utwente.nl
2008-03-17 10:13:18 UTC
Permalink
-----Original Message-----
Behalf Of jiho
Sent: vrijdag 14 maart 2008 18:21
To: Joel Holdsworth; inkscape-devel Devel
Subject: Re: [Inkscape-devel] DVCS again
you can see the previous message on forked thread about that
("DVCS again"). TortoiseHG and TortoiseBZR exists,
TortoiseGIT does not. I don't know the status of the first
two compared to TortoiseSVN.
still reading up on this thread, but I think this is important:
Aaron Spike
2008-03-17 11:55:46 UTC
Permalink
Aaron Spike
2008-03-14 12:04:07 UTC
Permalink
Post by jiho
Since this supposes a lot of branching (for SoC, probably also for
many large scale changes because the tree still needs to be usable
during that time etc.) wouldn't it be a good time to change version
control system to something that eases branching and merging? Plus,
distributed version control would ease a model where changes are
reviewed by several people before they are committed to the main tree
(i.e. just pull the changes from other people's trees and allow
commits to the main tree only by the reviewers). The discussions on
the list about this are old and quite long and to summarize them in a
- everybody agreed that there are solutions superior to svn in all
point of views
- the contenders are git, mercurial and bazaar
- all of them are pretty equivalent in terms of basic functionality now
- compare to basic svn usage (update, status, diff, commit, log) all
of them should be close enough so that they don't demand much learning
by developers used to only svn
- in all of them it should be possible to hook a check mechanism after
each commit (which would probably prove very useful in the context of
re-factoring to check the changes for 'make check' passing or other
custom test suite)
Now for the specific benefits/problems associated which each one (I
know git a little, not the others, so please fill in the blanks and
correct my mistakes so that we can come up with a clear list to decide
I think this would be a great time to encourage DVCS usage among the
developers. But until a number of us have some experience from which to
speak about the products, making a decision to use one would make me
nervous.

As you may know a few people are already using DVCS systems to do their
work on inkscape. Ted uses SVK (you can tell by the number of times that
his commit messages say "SVK screwed up the last commit" :-) ). Mental
uses git-svn (he described his use of git-svn for jruby at
http://moonbase.rydia.net/mental/blog/programming/using-git-svn-for-jruby).
I've heard that a similar workflow is possible with bzr
(http://bazaar-vcs.org/BzrForeignBranches/Subversion). I have not heard
anything of hg but I would expect something similar. We can try these
tools now, without switching over the entire repo.

Having said that perhaps there is some worth in switching now.
Post by jiho
-- GIT ----------------------------
Good
- very fast (but anything would be faster than svn anyway)
- allows to stash away local changes to fix a small issue. probably
useful when, in the middle of a large code change, one notices a local
bug which does not have anything to do with the change (not sure this
is git-only)
- ability to follow chunk of codes around, without relying on file
names. Probably useful from a refactoring point of view
- probably the fastest growing user base => many tools
Bad
- does not run too well on windows
-- HG -----------------------------
Good
Bad
-- BZR ----------------------------
Good
- already integrated in launchpad
- supports renames (could be considered a Bad by git users)
- supports bundling changesets
-
Post by jiho
Bad
Aaron
Aaron Spike
2008-03-14 12:15:58 UTC
Permalink
Post by jiho
-- GIT ----------------------------
Bad
- does not run too well on windows
I'm not sure this is fair to say anymore. I've used git to branch a few
repos onto a winxp box without issue. I haven't used it for much work at
all but the simple features seemed to work at first glance. I would
encourage some of the other win32 devs to give it a whirl.

http://code.google.com/p/msysgit/

And maybe someone would be interested enough to put a little work into:

http://repo.or.cz/w/git-cheetah.git/

Aaron Spike
Aaron Spike
2008-03-14 12:24:33 UTC
Permalink
Post by Aaron Spike
Post by jiho
-- GIT ----------------------------
Bad
- does not run too well on windows
I'm not sure this is fair to say anymore. I've used git to branch a few
repos onto a winxp box without issue. I haven't used it for much work at
all but the simple features seemed to work at first glance. I would
encourage some of the other win32 devs to give it a whirl.
Apparently there is some progress on git-svn on windows too!

http://groups.google.com/group/msysgit/browse_thread/thread/4fe38865bdc6a862/f41a8a9fe840ab4f#f41a8a9fe840ab4f

Aaron
jiho
2008-03-14 12:34:54 UTC
Permalink
Post by Aaron Spike
Post by jiho
-- GIT ----------------------------
Bad
- does not run too well on windows
I'm not sure this is fair to say anymore. I've used git to branch a few
repos onto a winxp box without issue. I haven't used it for much work at
all but the simple features seemed to work at first glance. I would
encourage some of the other win32 devs to give it a whirl.
http://code.google.com/p/msysgit/
http://repo.or.cz/w/git-cheetah.git/
That's good news (I, too, "wouldn't mind" if git was chosen ;)). Is it
easy to install and all or is it just "grab the source and compile it
yourself" for now?

JiHO
---
http://jo.irisson.free.fr/
jiho
2008-03-14 13:03:04 UTC
Permalink
Post by jiho
Post by Aaron Spike
Post by jiho
-- GIT ----------------------------
Bad
- does not run too well on windows
I'm not sure this is fair to say anymore. I've used git to branch a few
repos onto a winxp box without issue. I haven't used it for much work at
all but the simple features seemed to work at first glance. I would
encourage some of the other win32 devs to give it a whirl.
http://code.google.com/p/msysgit/
http://repo.or.cz/w/git-cheetah.git/
That's good news (I, too, "wouldn't mind" if git was chosen ;)). Is
it easy to install and all or is it just "grab the source and
compile it yourself" for now?
don't bother. I should have clicked through a little bit. there's an
installer.

JiHO
---
http://jo.irisson.free.fr/
J***@ewi.utwente.nl
2008-03-17 10:05:23 UTC
Permalink
Post by jiho
Since this supposes a lot of branching (for SoC, probably also for
many large scale changes because the tree still needs to be usable
during that time etc.) wouldn't it be a good time to change version
control system to something that eases branching and merging?
I branched and merged a lot for GSoC 2007. Merging and branching *is* easy in SVN.
Post by jiho
Plus,
distributed version control would ease a model where changes are
reviewed by several people before they are committed to the main tree
(i.e. just pull the changes from other people's trees and allow
commits to the main tree only by the reviewers).
I am opposed to such a working model. Reviewing would be a fulltime job, and not that much of fun (count me out!). Who will have enough knowledge of allll of inkscape anyway? One of the nice things about TortoiseSVN: when you do an SVN update, you can press the view log button that then shows *only* the log of revisions since the last svn update. This way it is very easy to keep track of what changed recently. Since the log UI of tortoisesvn is quite nice, you can see which files changed click on it to see the diff. Makes for easy reviewing when one wants it (I often check files of which I know the code), but does not demand reviewing.


I am very much against doing offline 'commits', just from what I see happening in practice. Although it is nice to be able to 'save' work when there is no internet connection available, it removes an *essential* part from the workflow: SVN Update and checking whether it still works, possibly checking source code changes.
I'm not sure whether everybody does this:
0. svn update
1. code stuff
2. svn update (!!!)
3. make
4. does it work? did merging go well?
5. svn commit

2-5 in rapid succession and needs internet. This at least ensures that we don't get ';' missing buildbreakage etc, but also removes more complex problems. I think any offline CVS method removes 2 to 5.

Regards,
Johan
Aaron Spike
2008-03-17 12:26:49 UTC
Permalink
Post by J***@ewi.utwente.nl
Post by jiho
Since this supposes a lot of branching (for SoC, probably also for
many large scale changes because the tree still needs to be usable
during that time etc.) wouldn't it be a good time to change version
control system to something that eases branching and merging?
I branched and merged a lot for GSoC 2007. Merging and branching *is* easy in SVN.
It is easy if you keep the proper workflow. But you still have to know
something. If you haven't done any work with a DVCS system you should
try one out at home with one of your pet projects for a week and see how
"easy" branching and merging really can be. In DVCS the system knows
which revisions are where so you don't have to keep track, you simply
tell it to merge this way or that and it does. No mental effort.
Post by J***@ewi.utwente.nl
Post by jiho
Plus,
distributed version control would ease a model where changes are
reviewed by several people before they are committed to the main tree
(i.e. just pull the changes from other people's trees and allow
commits to the main tree only by the reviewers).
I am opposed to such a working model. Reviewing would be a fulltime
job, and not that much of fun (count me out!). Who will have enough
knowledge of allll of inkscape anyway?
I think I agree here. In the Inkscape project we don't follow such a
model. We are very open with committer access and that is one of the
reasons for the project's success.
Post by J***@ewi.utwente.nl
One of the nice things about
TortoiseSVN: when you do an SVN update, you can press the view log
button that then shows *only* the log of revisions since the last svn
update. This way it is very easy to keep track of what changed recently.
Since the log UI of tortoisesvn is quite nice, you can see which files
changed click on it to see the diff. Makes for easy reviewing when one
wants it (I often check files of which I know the code), but does not
demand reviewing.
I think the workflow for a DVCS is a bit different. For example I keep
one branch to track the state of the main repo and another branch for
each task I'm currently working on (branches rather than separate
checkouts). Now I can update the state of the tracking branch as often
as I want (independently of my working branch, like you are used to in
svn). And because the system knows which revisions are in which branches
I can check the log at anytime and get just the new commits by comparing
the commits on each branch. In git the command for this is called `git
whatchanged`. Also one of the things I noticed is that any use of the
log functionality in TortoiseSVN was unbearably slow because it requires
network access. A DVCS stores all this information locally, so the logs
become much more useful and accessible. I think you'll appreciate this.
Post by J***@ewi.utwente.nl
I am very much against doing offline 'commits', just from what I see
happening in practice. Although it is nice to be able to 'save' work
when there is no internet connection available, it removes an
*essential* part from the workflow: SVN Update and checking whether it
still works, possibly checking source code changes.
0. svn update
1. code stuff
2. svn update (!!!)
3. make
4. does it work? did merging go well?
5. svn commit
2-5 in rapid succession and needs internet. This at least ensures
that we don't get ';' missing buildbreakage etc, but also removes
more complex problems. I think any offline CVS method removes 2 to 5.
I really don't understand why you think that a DVCS would cause people
to practice any worse VCS hygiene than now. DVCS gives you freedom to
commit in smaller logical blocks. As a person who worked with branches
in SVN extensively you should understand the utility of this. You likely
committed much more frequently on your branch than you would have
committed to trunk. The diffs were smaller and easier to read. The
commit messages were more granular and more meaningful. And when working
on a branch svn update is equivalent to merge. You didn't merge for
every commit. You had the freedom to work out an idea while committing
bite-sized pieces and dealing with the integration problems when you
chose to. But you still dealt with them. As things are now many people
keep large sets of changes in their local tree and work, effectively,
without the help of version control day to day. Bulia, for one, likes to
drop large changesets on us. I think he will benefit tremendously from
DVCS. Think of it as a unification of team VCS and your very own
personal VCS. A work flow might look like this:

0. check out HEAD branch from central repo
1. branch "topic"
2. code a bit, test, commit.
3. code a bit, test, commit.
...
4. fetch changes from central repo into HEAD
5. merge HEAD into "topic"
6. fix, test, commit
7. code a bit, test, commit.
8. code a bit, test, commit.
**finished new functionality or refactoring**
9. fetch changes from central repo into HEAD
10. merge HEAD into "topic"
11. fix, test, commit
12. push topic changes to central repo
jiho
2008-03-17 12:56:46 UTC
Permalink
Post by Aaron Spike
Post by J***@ewi.utwente.nl
Post by jiho
Plus,
distributed version control would ease a model where changes are
reviewed by several people before they are committed to the main tree
(i.e. just pull the changes from other people's trees and allow
commits to the main tree only by the reviewers).
I am opposed to such a working model. Reviewing would be a fulltime
job, and not that much of fun (count me out!). Who will have enough
knowledge of allll of inkscape anyway?
I think I agree here. In the Inkscape project we don't follow such a
model. We are very open with committer access and that is one of the
reasons for the project's success.
Just to clarify about this. I know that this is not Inkscape's current
workflow and probably should not become it in the future either (if I
understood things well, Sodipodi used such a kind of hierarchical
workflow and this was not really appreciated by the folks now working
on Inkscape ;) ). I mentioned this here in the context of refactoring,
where Bryce suggested:
[...] I'd like to suggest the following principles:
...
* Hold code review parties with 2-3 others to brainstorm
...
I just wanted to mention that a DVCS could ease that part very much by
allowing a few people to pull from others and then one of the
reviewers to push that to the central repo once the change set is
done. Maybe my words were a bit strong in saying that committing to
the central repo would be restricted to only a few people. The
workflow was really what I wanted to point out.

JiHO
---
http://jo.irisson.free.fr/
jiho
2008-03-17 13:29:06 UTC
Permalink
Since the thread is becoming long and has many forks (making it
difficult to follow) I made a wiki page where I tried to summarize
what was said here:
http://wiki.inkscape.org/wiki/index.php/Change_VCS
It would benefit from review by other people who have followed the
thread. In particular adding a proper speed comparison with Inkscape
tree in all systems would probably be valuable. Then updating stuff on
this page together with emails on the list would make the current
status of the discussion easier to follow.
I also added a DVCS vs SVN section, which is to be expanded (I just
did not felt courageous enough to dig inside the email archive and
exhume the old threads on the subject). For people thinking it is
still a concern, please add your opinion there.

JiHO
---
http://jo.irisson.free.fr/
J***@ewi.utwente.nl
2008-03-17 17:01:48 UTC
Permalink
-----Original Message-----
Sent: maandag 17 maart 2008 13:27
one of the things I noticed is that any use of the log
functionality in TortoiseSVN was unbearably slow because it
requires network access. A DVCS stores all this information
locally, so the logs become much more useful and accessible.
I think you'll appreciate this.
This does indeed sound nice. So, DVCS stores *all* info offline? (A log without diffs is useless for me)
Although I am used to having 100Mbps internet, I don't find SVN slow on my current wireless connection (don't know the exact speed... it's cable. 2Mbps or something).
But in any case, an offline history might be nice I guess.
I really don't understand why you think that a DVCS would
cause people to practice any worse VCS hygiene than now. DVCS
gives you freedom to commit in smaller logical blocks. As a
person who worked with branches in SVN extensively you should
understand the utility of this. You likely committed much
more frequently on your branch than you would have committed
to trunk. The diffs were smaller and easier to read. The
commit messages were more granular and more meaningful. And
when working on a branch svn update is equivalent to merge.
You didn't merge for every commit. You had the freedom to
work out an idea while committing bite-sized pieces and
dealing with the integration problems when you chose to. But
you still dealt with them.
About my gsoc2007 svn experience/method: the frequent committing was mainly because of switching PC's actually and was possible because I was the only one committing to the branch. I think it is actually very unclear to commit in small chunks. Especially for reviewing or trying to understand what was needed for certain functionality. Perhaps the diff comments were more meaningful, but that's because it is more diffcomment text, because it is only meaningful in the context of all the other commits. Reverting one of those commits would be useless, you'd have to revert 10 successive ones. When people want more meaningful diffcomments, I think we should write longer diffcomments instead of doing more commits.

I am very afraid I will loose all nice features that SVN/Tortoise gives me now, without gaining anything myself. When reading TortoiseBZR:
"TODO: Enable add, merge, log, revert, etc context menu options."
:'(

Making your own local "branch" offline is already very easy btw: just copy your inkscape checkout, including already compiled files for fine speedy rebuild. It's what I sometimes do when working on a large thing for multiple days.

I think, grass is always much greener on the neighbour's lawn.

Regards,
Johan
Terry Brown
2008-03-17 17:49:49 UTC
Permalink
On Mon, 17 Mar 2008 18:01:48 +0100
Post by J***@ewi.utwente.nl
I think it is actually
very unclear to commit in small chunks.
Only your local, "personal", commits are likely to be "small chunks",
others won't see them, and you don't have to make them unless you
want. Personally I think it's great to be able to regularly
"Save Game" locally and then merge / push to the shared system when
I've actually accomplished something.

The leo-editor project I hack on a bit has just moved from CVS to
launchpad/bzr. It's a smaller project than inkscape, but generally the
transition has been a good thing. There's the EOLs of course, but you
can deal with those. And bzr can accommodate almost any workflow, it
can behave like CVS if you want... this is good but makes it a little
confusing at first, although I think that can be overcome by more
experienced users sharing recipes, that's what happened on the
leo-editor project.
Post by J***@ewi.utwente.nl
I think, grass is always much greener on the neighbour's lawn.
:-) good point, but I don't think there's much question than bzr/git/hg
are more flexible, productive models than SVN - not that that helps if
you want a friendly gui for bzr and there isn't one. I suspect that
command line use is simpler in bzr than svn though.

Cheers -Terry
jiho
2008-03-17 17:45:32 UTC
Permalink
Post by J***@ewi.utwente.nl
Sent: maandag 17 maart 2008 13:27
one of the things I noticed is that any use of the log
functionality in TortoiseSVN was unbearably slow because it
requires network access. A DVCS stores all this information
locally, so the logs become much more useful and accessible.
I think you'll appreciate this.
This does indeed sound nice. So, DVCS stores *all* info offline? (A
log without diffs is useless for me)
Although I am used to having 100Mbps internet, I don't find SVN slow
on my current wireless connection (don't know the exact speed...
it's cable. 2Mbps or something).
But in any case, an offline history might be nice I guess.
Yes it does. everything is available offline (expect push to a remote
repository obviously). As for speed, I guess that it is only possible
to really feel the difference by trying it. Once you get used to an
immediate status or log it becomes a pain to wait even 2-4 s for it ;)
Post by J***@ewi.utwente.nl
I really don't understand why you think that a DVCS would
cause people to practice any worse VCS hygiene than now. DVCS
gives you freedom to commit in smaller logical blocks. As a
person who worked with branches in SVN extensively you should
understand the utility of this. You likely committed much
more frequently on your branch than you would have committed
to trunk. The diffs were smaller and easier to read. The
commit messages were more granular and more meaningful. And
when working on a branch svn update is equivalent to merge.
You didn't merge for every commit. You had the freedom to
work out an idea while committing bite-sized pieces and
dealing with the integration problems when you chose to. But
you still dealt with them.
About my gsoc2007 svn experience/method: the frequent committing was
mainly because of switching PC's actually and was possible because I
was the only one committing to the branch. I think it is actually
very unclear to commit in small chunks. Especially for reviewing or
trying to understand what was needed for certain functionality.
The equivalent diff in a DVCS would be the one you push to the central
repository.
Post by J***@ewi.utwente.nl
Perhaps the diff comments were more meaningful, but that's because
it is more diffcomment text, because it is only meaningful in the
context of all the other commits. Reverting one of those commits
would be useless, you'd have to revert 10 successive ones. When
people want more meaningful diffcomments, I think we should write
longer diffcomments instead of doing more commits.
I am very afraid I will loose all nice features that SVN/Tortoise
gives me now, without gaining anything myself. When reading
"TODO: Enable add, merge, log, revert, etc context menu options."
:'(
This, I am afraid, is likely... But that's probably a chicken and egg
problem: when enough people use those, the tools will probably improve.
Post by J***@ewi.utwente.nl
just copy your inkscape checkout, including already compiled files
for fine speedy rebuild. It's what I sometimes do when working on a
large thing for multiple days.
But you cannot commit to it. This is what a DVCS would bring you.
Post by J***@ewi.utwente.nl
I think, grass is always much greener on the neighbour's lawn.
I think that seeing many other major projects move towards these tools
may be reassuring in this respect. If you have a little time free,
reading about those can be insightful (bazaar wiki is particularly
rich):
http://bazaar-vcs.org/BzrWhy
or there's always the google talk videos about git (watching a video
is always nice right;) ):
http://video.google.com/videoplay?docid=-2199332044603874737


JiHO
---
http://jo.irisson.free.fr/
Ted Gould
2008-03-17 17:47:04 UTC
Permalink
Post by Aaron Spike
Post by J***@ewi.utwente.nl
One of the nice things about
TortoiseSVN: when you do an SVN update, you can press the view log
button that then shows *only* the log of revisions since the last svn
update. This way it is very easy to keep track of what changed recently.
Since the log UI of tortoisesvn is quite nice, you can see which files
changed click on it to see the diff. Makes for easy reviewing when one
wants it (I often check files of which I know the code), but does not
demand reviewing.
I think the workflow for a DVCS is a bit different. For example I keep
one branch to track the state of the main repo and another branch for
each task I'm currently working on (branches rather than separate
checkouts). Now I can update the state of the tracking branch as often
as I want (independently of my working branch, like you are used to in
svn). And because the system knows which revisions are in which branches
I can check the log at anytime and get just the new commits by comparing
the commits on each branch. In git the command for this is called `git
whatchanged`. Also one of the things I noticed is that any use of the
log functionality in TortoiseSVN was unbearably slow because it requires
network access. A DVCS stores all this information locally, so the logs
become much more useful and accessible. I think you'll appreciate this.
I'd agree with this, but I'll also note that it makes you lazy when
you're trying to work with SVN at the base. I think Bryce was very
unhappy when I sent a large patch for 0.46 and while it was broken into
nice easy chunks on my branch I had no way to communicate that easily
for integration into SVN.

This is also the reason that I'd like to have hosting available. I'm
sure I could set up my git hosting, but I'd prefer not to. Sometimes I
am working on things that other people would be interested in, but it
stays on my computer because it's simpler that way. Being able to push
stuff out there before committing it to the main repository would help
my workflow.

I'll also comment (in a way that will probably get lost in this thread)
that we need to give some lead time before a switch. Right now my SVK
branch has changes on it, and I don't think any solution we choose will
import from SVK nicely :) So, I need to finish and merge them before we
switch.

--Ted
jiho
2008-03-17 22:41:28 UTC
Permalink
Post by Ted Gould
I'll also comment (in a way that will probably get lost in this thread)
that we need to give some lead time before a switch. Right now my SVK
branch has changes on it, and I don't think any solution we choose will
import from SVK nicely :) So, I need to finish and merge them
before we
switch.
Well git wiki page says: "Subversion and svk repositories can be used
directly with git-svn"

JiHO
---
http://jo.irisson.free.fr/

MenTaLguY
2008-03-17 16:22:23 UTC
Permalink
Post by J***@ewi.utwente.nl
I am very much against doing offline 'commits', just from what I see
happening in practice. Although it is nice to be able to 'save' work when
there is no internet connection available, it removes an *essential* part
from the workflow: SVN Update and checking whether it still works,
possibly checking source code changes.
0. svn update
1. code stuff
2. svn update (!!!)
3. make
4. does it work? did merging go well?
5. svn commit
2-5 in rapid succession and needs internet. This at least ensures that we
don't get ';' missing buildbreakage etc, but also removes more complex
problems. I think any offline CVS method removes 2 to 5.
This isn't a real issue; with a distributed SCM you still have to merge
your local commits with upstream before the system will let you push
them upstream.

-mental
jiho
2008-03-14 13:07:29 UTC
Permalink
Post by Aaron Spike
Post by jiho
Since this supposes a lot of branching (for SoC, probably also for
many large scale changes because the tree still needs to be usable
during that time etc.) wouldn't it be a good time to change
version control system to something that eases branching and
merging? [...]
I think this would be a great time to encourage DVCS usage among the
developers. But until a number of us have some experience from which
to speak about the products, making a decision to use one would make
me nervous.
Bryce Harrington
2008-03-14 20:05:17 UTC
Permalink
Post by Aaron Spike
As you may know a few people are already using DVCS systems to do
their work on inkscape. Ted uses SVK (you can tell by the number of
times that his commit messages say "SVK screwed up the last
commit" :-) ). Mental uses git-svn (he described his use of git-svn
for jruby at http://moonbase.rydia.net/mental/blog/programming/using-git-svn-for-jruby)
. I've heard that a similar workflow is possible with bzr (http://bazaar-vcs.org/BzrForeignBranches/Subversion
). I have not heard anything of hg but I would expect something
similar. We can try these tools now, without switching over the
entire repo.
Having said that perhaps there is some worth in switching now.
I know git-svn for using it with all my svn-based repos now. It works
nicely indeed. However, I still think the best solution would be to
- it would not cost much to each dev (for git at least, skimming over http://git.or.cz/course/svn.html
takes 5 minutes, reading it thoroughly takes 30. not a big deal)
- it would avoid a two step process for everyone (svn co first and
then git-svn init if the person wants to do refactoring work on his/
her side)
- the only situation I see where svn is superior is regarding the
integration with online repository browsers and tracking systems such
as Trac (there are plugins for git etc. but svn is the default and
better supported). But Inkscape do not use such a thing anyway and the
online browser of SourceForge is crap enough to be worth replacing by
git's web interface. NB: I never used the new interface in Launchpad.
I don't know wether it would integrate with git.
I agree this is the right time to talk about switching the repo. Not
only to upgrade from SVN, but because SourceForge's SVN service is
imperfect (this last month in the middle of our release they expired
everyone's SVN passwords with no notice or reason given).
OK, now I think others probably have more informed opinions. Please
copy the point by point summary below and add to it.
-- GIT ----------------------------
Good
- very fast (but anything would be faster than svn anyway)
- allows to stash away local changes to fix a small issue. probably
useful when, in the middle of a large code change, one notices a
local bug which does not have anything to do with the change (not
sure this is git-only)
- ability to follow chunk of codes around, without relying on file
names. Probably useful from a refactoring point of view
- probably the fastest growing user base => many tools
- TextMate bundle
(What is TextMate?)
Bad
- Git is designed with the Linux kernel's hierarchical workflow in mind,
so may require alteration in how Inkscape's workflow works.
- We would need to set up and administer this ourselves
- Revisions are indicated with SHA's rather than numbers
- Commands dissimilar to what we're used to with svn
(e.g., no 'git update')
-- HG -----------------------------
Good
- tortoiseHG
- TextMate bundle
Bad
-- BZR ----------------------------
Good
- already integrated in launchpad
http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.html
+ Associating branches to bugs
+ Associating branches to blueprints
+ Changes state of bugs in LP when committing in Bazaar
+ Web interface for creating branches quickly and easily
- supports renames (could be considered a Bad by git users)
- supports bundling changesets
- tortoiseBZR
- Fewer commands and built-in help - makes it easier to learn
- Supports multiple workflows, including what we use for Inkscape.
(See http://bazaar-vcs.org/Workflows)
- Many plugins
- Easy administration. Mostly done through Launchpad, plus Bzr folks
are available to help.
- Git uses SHAs for revisions (e.g. 824853772241acf64bc37ac8b85254194741ae13)
where bzr uses numbers (e.g., 1, 2, 3.2, 63.3.5.9). bzr has UUIDs
internally, but not needed in day-to-day use.
Bad
---
I happened to be working on two small new projects with other folks in
recent months, one under git, the other under bzr, which for me
highlighted the benefits of bzr.

For the bzr project, I essentially needed to branch an existing codebase
and make some small modifications to it. I located the project on
Launchpad, and on the 'code' tab clicked 'Register branch', and it gave
me the command to upload my branched code. A few minutes later I was
off and running. I hadn't studied any git commands, but just guessed
based on my svn experience and everything worked as I expected.

For the git project, the other contributor strongly wanted git, because
it was his aim for the code to be adopted by debian. I went through the
guidelines for setting up a git repo at debian (took a couple hours to
get it all sorted out properly), and let the contributor know. He did
not actually know git, so it took him some time to get up to speed, but
before long he was sending me diffs to integrate. However, having to
wait for me to commit his work created an annoying bottleneck. Perhaps
someone with more git know-how would know how to enable multiple
committers, but it was not obvious to us git neophytes. Finally, the
other contributor switched us over to bzr, and there's been no trouble
since.

In both cases, I could take advantage of the distributed form, doing
commits for each change individually, and then running a '*** push' when
ready to share publically. There wasn't much performance difference
with commits between the two, however I did notice git to be faster on
pushes, but bzr was definitely fast enough - no more than the time to
take a sip of coffee; definitely faster than svn.

There were also a lot of other little differences that made bzr a bit
more convienent. For instance, in git if you make changes to several
files, you have individually do 'git add' to each in order for them to
be included in the commit, or you can do 'git commit -a' which commits
all changes. In either case it's different than you'd expect. In bzr,
you just do 'bzr commit' and it commits all changes, just like svn.

I've also done merges in git and bzr. With git, the first time I did a
merge it was a minor nightmare trying to figure out what options I
needed to run. So I was apprehensive the first time I was asked to do a
bzr merge. However, it was almost trivially easy.


Bryce
jiho
2008-03-14 21:17:40 UTC
Permalink
Post by Bryce Harrington
[..]. We can try these tools now, without switching over the
entire repo.
[..]
However, I still think the best solution would be to
[...]
I agree this is the right time to talk about switching the repo. Not
only to upgrade from SVN, but because SourceForge's SVN service is
imperfect (this last month in the middle of our release they expired
everyone's SVN passwords with no notice or reason given).
- TextMate bundle
(What is TextMate?)
TextMate is a (very very cool ;) ) editor for OS X: http://macromates.com/
The reason why I mentioned it is because, first, it is very popular
and, second, since there is no real equivalent to TortoiseSVN on OS X,
people usually rely on their editor/IDE to provide an interface to
version control.

<digression>
TextMate provides an interface for SVN, Git and Mercurial, through
collaboratively developed bundles, nothing for bazaar (this project is
quite odd: the editor itself is shareware and definitely closed but
the development of functionality goes through language bundles which
are community driven. In this respect it is very much like any average
OS project). However I may be able to come up with something for
bazaar in June: the basic functionality is made available by TextMate
core. What's missing are a nice set of scripts to glue all that
together, and, this, I know how to do iven a little time ;)
Fore those wondering, there is a windows equivalent of TM: E http://www.e-texteditor.com/
. Sadly, nothing on linux but "port to linux" is probably the N# 1
request on TextMate's ticket system. I must admit that this is also
the N# 1 reason that made me buy another mac and stick on OS X instead
of switching to Ubuntu. It's that good.
</digression>

OK, summary and comments:

-- GIT ----------------------------
+ maybe a bit faster at commits
+ allows to stash away local changes to fix a small issue. probably
useful when, in the middle of a large code change, one notices a
local bug which does not have anything to do with the change
-> not sure this is git-only
+ ability to follow chunk of codes around, without relying on file
names. Probably useful from a refactoring point of view
+ probably the fastest growing user base => many tools
+ TextMate bundle

- git is designed with the Linux kernel's hierarchical workflow in
mind (few 'push'ers to the central repos), so may require alteration
in how Inkscape's workflow works (anyone of the numerous contributors
can commit)
-> this workflow may be particularly suited for the refactoring part
though, it would force code review
- we would need to set up and administer this ourselves
-> anything moving us from sourceforge would be the same, wouldn't
it? and moving from sourceforge seemed like a good thing (cf. you,
above)
- revisions are indicated with SHA's rather than numbers
- commands dissimilar to what we're used to with svn (e.g., no 'git
update')
- have to git add all modified files before committing them (or resort
to a non specific commit -a)


-- HG -----------------------------
+ tortoiseHG
+ TextMate bundle


-- BZR ----------------------------
+ already integrated in launchpad:
http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.html
+ Associating branches to bugs
+ Associating branches to blueprints
+ Changes state of bugs in LP when committing in Bazaar
+ Web interface for creating branches quickly and easily
+ supports renames (could be considered a Bad by git users)
+ supports bundling changesets
+ tortoiseBZR
+ Fewer commands - makes it easier to learn
-> suppressed built-in help since it is probably true for all of them
(git help and man page are OK and I can't imagine that Hg does not
have help)
+ Supports multiple workflows, including what we use for Inkscape (See http://bazaar-vcs.org/Workflows)
+ Many plugins
-> not sure what this means
+ Easy administration. Mostly done through Launchpad, plus Bzr folks
are available to help.
+ bzr uses numbers for revisions(e.g., 1, 2, 3.2, 63.3.5.9). bzr has
UUIDs internally, but not needed in day-to-day use.


Bazaar looks very cool. Bu is there anything like stash in bzr? It is
incredibly useful and I suspect it will be even more when people will
start looking at the code in more detail during refactoring.

JiHO
---
http://jo.irisson.free.fr/
Aaron Spike
2008-03-14 22:03:31 UTC
Permalink
Post by jiho
Bazaar looks very cool. Bu is there anything like stash in bzr?
bzr shelve
jiho
2008-03-14 22:20:12 UTC
Permalink
Post by Aaron Spike
Post by jiho
Bazaar looks very cool. Bu is there anything like stash in bzr?
bzr shelve
Ok then stash is not git's advantage anymore:

-- GIT ----------------------------
+ maybe a bit faster at commits
+ ability to follow chunk of codes around, without relying on file
names. Probably useful from a refactoring point of view
+ probably the fastest growing user base => many tools
+ TextMate bundle

- git is designed with the Linux kernel's hierarchical workflow in
mind (few 'push'ers to the central repos), so may require alteration
in how Inkscape's workflow works (anyone of the numerous contributors
can commit)
- we would need to set up and administer this ourselves
seemed like a good thing (cf. you, above)
- revisions are indicated with SHA's rather than numbers
- commands dissimilar to what we're used to with svn (e.g., no 'git
update')
- have to git add all modified files before committing them (or resort
to a non specific commit -a)


-- HG -----------------------------
+ tortoiseHG
+ TextMate bundle


-- BZR ----------------------------
+ already integrated in launchpad:
http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.html
+ Associating branches to bugs
+ Associating branches to blueprints
+ Changes state of bugs in LP when committing in Bazaar
+ Web interface for creating branches quickly and easily
+ supports renames (could be considered a Bad by git users)
+ supports bundling changesets
+ tortoiseBZR
+ Fewer commands - makes it easier to learn
+ Supports multiple workflows, including what we use for Inkscape (See http://bazaar-vcs.org/Workflows)
+ Easy administration. Mostly done through Launchpad, plus Bzr folks
are available to help.
+ bzr uses numbers for revisions(e.g., 1, 2, 3.2, 63.3.5.9). bzr has
UUIDs internally, but not needed in day-to-day use.


JiHO
---
http://jo.irisson.free.fr/
Ted Gould
2008-03-14 22:55:27 UTC
Permalink
Post by jiho
-- BZR ----------------------------
http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.html
+ Associating branches to bugs
+ Associating branches to blueprints
+ Changes state of bugs in LP when committing in Bazaar
+ Web interface for creating branches quickly and easily
I don't know if this is overlap, but I think a strong advantage of BZR
is that there is publicly available hosting. So if a new contributor
wants to provide a change they either have to make a diff, or find some
way to host their branch. The later is taken care of already for us in
the BZR case. So, I guess the bullet point is:

+ publicly available hosting

The other BZR plus for me is the PQM solution where one can set up a
situation where something like "make check" is run on every commit.
(see Jon's earlier e-mail) I realize this could be built with other
systems, but again it is already build and maintained for us. Bullet:

+ commit based build checking tool available

A minor plus:

+ Bazaar is a part of the GNU project

And lastly:

+ Ted's used it before and hasn't been offended ;)

--Ted
MenTaLguY
2008-03-14 23:00:42 UTC
Permalink
Post by Ted Gould
I don't know if this is overlap, but I think a strong advantage of BZR
is that there is publicly available hosting. So if a new contributor
wants to provide a change they either have to make a diff, or find some
way to host their branch. The later is taken care of already for us in
+ publicly available hosting
Well, not only that, but the bzr accounts would be integrated with the
accounts for our bug tracker too.

-mental
jiho
2008-03-14 23:21:47 UTC
Permalink
Post by MenTaLguY
Post by Ted Gould
I don't know if this is overlap, but I think a strong advantage of BZR
is that there is publicly available hosting. So if a new contributor
wants to provide a change they either have to make a diff, or find some
way to host their branch. The later is taken care of already for us in
+ publicly available hosting
Well, not only that, but the bzr accounts would be integrated with the
accounts for our bug tracker too.
I'm not sure there's really a need to continue counting points right
now. It seems bazaar is the clear winner. Is there someone with a
strong opinion about that? Who's organising the switch? ;)
Post by MenTaLguY
+ Ted's used it before and hasn't been offended ;)
That was the selling point for me :P

JiHO
---
http://jo.irisson.free.fr/
MenTaLguY
2008-03-15 00:05:16 UTC
Permalink
Post by jiho
I'm not sure there's really a need to continue counting points right
now. It seems bazaar is the clear winner. Is there someone with a
strong opinion about that? Who's organising the switch? ;)
Well, first I think we need to do a trial import into bzr to make sure
that performance is acceptable?

-mental
Ted Gould
2008-03-15 02:47:35 UTC
Permalink
Post by MenTaLguY
Post by jiho
I'm not sure there's really a need to continue counting points right
now. It seems bazaar is the clear winner. Is there someone with a
strong opinion about that? Who's organising the switch? ;)
Well, first I think we need to do a trial import into bzr to make sure
that performance is acceptable?
https://code.edge.launchpad.net/~vcs-imports/inkscape/main

Unfortunately the vcs-imports are only available via http, which is
slower that the bzr+ssh protocol. But, if you build a branch in your
account you can pull that in and then push and do what ever in your
branch with bzr+ssh.

--Ted
Ted Gould
2008-03-15 04:35:55 UTC
Permalink
Post by MenTaLguY
Post by jiho
I'm not sure there's really a need to continue counting points right
now. It seems bazaar is the clear winner. Is there someone with a
strong opinion about that? Who's organising the switch? ;)
Well, first I think we need to do a trial import into bzr to make sure
that performance is acceptable?
I don't know what you define there, but I was curious. So I branched
the import (10 minutes) changed the changelog and pushed it into a
private branch (35 minutes). Made another change to the changelog and
pushed it (15 seconds). The whole repository is about 80 MB and my DSL
is 768/128.

Any other metrics?

--Ted
Bryce Harrington
2008-03-15 06:49:53 UTC
Permalink
Post by Ted Gould
Post by MenTaLguY
Post by jiho
I'm not sure there's really a need to continue counting points right
now. It seems bazaar is the clear winner. Is there someone with a
strong opinion about that? Who's organising the switch? ;)
Well, first I think we need to do a trial import into bzr to make sure
that performance is acceptable?
I don't know what you define there, but I was curious. So I branched
the import (10 minutes) changed the changelog and pushed it into a
private branch (35 minutes). Made another change to the changelog and
pushed it (15 seconds). The whole repository is about 80 MB and my DSL
is 768/128.
Any other metrics?
To give another data point, I branched ted's branch (6m15.4s), modified
the Changelog, committed locally (13.1s), registered a new branch that
anyone on the Inkscape-Admin team can commit to, and then pushed up the
new branch (39m19.8s). A local commit to Changelog took 2.8s, and push
took 15.4 sec (these are more representative of day-to-day work). I
then proposed to merge into Ted's branch. This is with Comcast
cablemodem with similar up/down rates as ted.

I also gave it a try on an account on one of the canonical.com servers.
branch: 46s, commit: 4.2s. So network performance seems to be a large
driver.

Anyone got comparable numbers for git?

Bryce
MenTaLguY
2008-03-15 20:46:47 UTC
Permalink
Post by Bryce Harrington
Post by Ted Gould
Post by MenTaLguY
Post by jiho
I'm not sure there's really a need to continue counting points right
now. It seems bazaar is the clear winner. Is there someone with a
strong opinion about that? Who's organising the switch? ;)
Well, first I think we need to do a trial import into bzr to make sure
that performance is acceptable?
I don't know what you define there, but I was curious. So I branched
the import (10 minutes) changed the changelog and pushed it into a
private branch (35 minutes). Made another change to the changelog and
pushed it (15 seconds). The whole repository is about 80 MB and my DSL
is 768/128.
Any other metrics?
To give another data point, I branched ted's branch (6m15.4s), modified
the Changelog, committed locally (13.1s), registered a new branch that
anyone on the Inkscape-Admin team can commit to, and then pushed up the
new branch (39m19.8s). A local commit to Changelog took 2.8s, and push
took 15.4 sec (these are more representative of day-to-day work). I
then proposed to merge into Ted's branch. This is with Comcast
cablemodem with similar up/down rates as ted.
I also gave it a try on an account on one of the canonical.com servers.
branch: 46s, commit: 4.2s. So network performance seems to be a large
driver.
For me, with git, a remote clone took about 5 minutes, pushing to a new
remote branch in the same remote repository took 4 seconds, pushing to a
new remote branch in a fresh remote repository took about 6 minutes, the
local commit took less than a second, and the subsequent push to an
established remote branch took just over a second.

Note that this was with the partial history since the switch to
subversion (since that's what I have easily available in git right now);
with a full history I would expect the times for remote initial clone or
push to be at least a little longer (though not linearly so, since git
sends deltas). Anyway, it sounds like git and bzr at least within the
same order of magnitude for cloning, so that's cool.

I'm not sure what's up with pushing, though; I find the idea of waiting
more than half an hour for a full push to be really appalling, I'm not
really keen on waiting 15 seconds for a trivial push to finish either,
and I'm kinda used to local commits being more or less instantaneous
(what is there to do that takes four seconds?).

I don't see that things are so bad for users accustomed to SVN, though.
The one issue I do see being a concern for SVN users is the initial
remote push time. With SVN, creating a new remote branch is effectively
instantaneous (as it is with git when you're branching within the same
repository). HALF AN HOUR is nuts!

Is there a way to have multiple branches in the same repository with
bzr, or faster ways to do it when both branches are hosted on the same
server?

-mental
Bryce Harrington
2008-03-16 19:56:59 UTC
Permalink
Post by MenTaLguY
Post by Bryce Harrington
Post by Ted Gould
Post by MenTaLguY
Post by jiho
I'm not sure there's really a need to continue counting points right
now. It seems bazaar is the clear winner. Is there someone with a
strong opinion about that? Who's organising the switch? ;)
Well, first I think we need to do a trial import into bzr to make sure
that performance is acceptable?
I don't know what you define there, but I was curious. So I branched
the import (10 minutes) changed the changelog and pushed it into a
private branch (35 minutes). Made another change to the changelog and
pushed it (15 seconds). The whole repository is about 80 MB and my DSL
is 768/128.
Any other metrics?
To give another data point, I branched ted's branch (6m15.4s), modified
the Changelog, committed locally (13.1s), registered a new branch that
anyone on the Inkscape-Admin team can commit to, and then pushed up the
new branch (39m19.8s). A local commit to Changelog took 2.8s, and push
took 15.4 sec (these are more representative of day-to-day work). I
then proposed to merge into Ted's branch. This is with Comcast
cablemodem with similar up/down rates as ted.
I also gave it a try on an account on one of the canonical.com servers.
branch: 46s, commit: 4.2s. So network performance seems to be a large
driver.
For me, with git, a remote clone took about 5 minutes, pushing to a new
remote branch in the same remote repository took 4 seconds, pushing to a
new remote branch in a fresh remote repository took about 6 minutes, the
local commit took less than a second, and the subsequent push to an
established remote branch took just over a second.
Just to make sure we're comparing apples to apples, would you mind also
repeating the procedure with bzr, so we can rule out differences in
network performance?

Bryce
john cliff
2008-03-16 20:09:13 UTC
Permalink
Do we have a reference point for SVN on any of these numbers?
Post by Bryce Harrington
Post by MenTaLguY
Post by Bryce Harrington
Post by Ted Gould
Post by MenTaLguY
Post by jiho
I'm not sure there's really a need to continue counting points
right
Post by MenTaLguY
Post by Bryce Harrington
Post by Ted Gould
Post by MenTaLguY
Post by jiho
now. It seems bazaar is the clear winner. Is there someone with
a
Post by MenTaLguY
Post by Bryce Harrington
Post by Ted Gould
Post by MenTaLguY
Post by jiho
strong opinion about that? Who's organising the switch? ;)
Well, first I think we need to do a trial import into bzr to make
sure
Post by MenTaLguY
Post by Bryce Harrington
Post by Ted Gould
Post by MenTaLguY
that performance is acceptable?
I don't know what you define there, but I was curious. So I
branched
Post by MenTaLguY
Post by Bryce Harrington
Post by Ted Gould
the import (10 minutes) changed the changelog and pushed it into a
private branch (35 minutes). Made another change to the changelog
and
Post by MenTaLguY
Post by Bryce Harrington
Post by Ted Gould
pushed it (15 seconds). The whole repository is about 80 MB and my
DSL
Post by MenTaLguY
Post by Bryce Harrington
Post by Ted Gould
is 768/128.
Any other metrics?
To give another data point, I branched ted's branch (6m15.4s),
modified
Post by MenTaLguY
Post by Bryce Harrington
the Changelog, committed locally (13.1s), registered a new branch that
anyone on the Inkscape-Admin team can commit to, and then pushed up
the
Post by MenTaLguY
Post by Bryce Harrington
new branch (39m19.8s). A local commit to Changelog took 2.8s, and
push
Post by MenTaLguY
Post by Bryce Harrington
took 15.4 sec (these are more representative of day-to-day work). I
then proposed to merge into Ted's branch. This is with Comcast
cablemodem with similar up/down rates as ted.
I also gave it a try on an account on one of the canonical.comservers.
branch: 46s, commit: 4.2s. So network performance seems to be a large
driver.
For me, with git, a remote clone took about 5 minutes, pushing to a new
remote branch in the same remote repository took 4 seconds, pushing to a
new remote branch in a fresh remote repository took about 6 minutes, the
local commit took less than a second, and the subsequent push to an
established remote branch took just over a second.
Just to make sure we're comparing apples to apples, would you mind also
repeating the procedure with bzr, so we can rule out differences in
network performance?
Bryce
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Inkscape-devel mailing list
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
MenTaLguY
2008-03-17 00:56:59 UTC
Permalink
Post by Bryce Harrington
Post by MenTaLguY
For me, with git, a remote clone took about 5 minutes, pushing to a new
remote branch in the same remote repository took 4 seconds, pushing to a
new remote branch in a fresh remote repository took about 6 minutes, the
local commit took less than a second, and the subsequent push to an
established remote branch took just over a second.
Just to make sure we're comparing apples to apples, would you mind also
repeating the procedure with bzr, so we can rule out differences in
network performance?
I get 5 minutes for branch, 17 minutes for remote push to a new branch,
4 seconds for commit, and 10 seconds for a push to an existing remote
branch.

The 17 minutes is a bit more livable, but I do wonder -- shouldn't there
be some way to have bzr branches hosted in the same location share
revision data, so you don't need to copy so much around?

-mental
Bryce Harrington
2008-03-17 01:03:48 UTC
Permalink
Post by MenTaLguY
Post by Bryce Harrington
Post by MenTaLguY
For me, with git, a remote clone took about 5 minutes, pushing to a new
remote branch in the same remote repository took 4 seconds, pushing to a
new remote branch in a fresh remote repository took about 6 minutes, the
local commit took less than a second, and the subsequent push to an
established remote branch took just over a second.
Just to make sure we're comparing apples to apples, would you mind also
repeating the procedure with bzr, so we can rule out differences in
network performance?
I get 5 minutes for branch, 17 minutes for remote push to a new branch,
4 seconds for commit, and 10 seconds for a push to an existing remote
branch.
So it sounds like except for the remote push, the numbers you're seeing
for bzr are roughly within range of what you're seeing with git?
Post by MenTaLguY
The 17 minutes is a bit more livable, but I do wonder -- shouldn't there
be some way to have bzr branches hosted in the same location share
revision data, so you don't need to copy so much around?
Yeah, see Martin Pool's response to my enquiry about this. It seems
that while launchpad makes it very simple & convenient to make branches,
the implementation currently deployed is not set up for shared storage.
Sounds like if cloning performance is a killer issue for us we could
self-host (in which case we lose the launchpad integration benefits),
until launchpad gains this ability.

Bryce
Jon A. Cruz
2008-03-15 02:50:49 UTC
Permalink
Post by jiho
I'm not sure there's really a need to continue counting points right
now. It seems bazaar is the clear winner. Is there someone with a
strong opinion about that? Who's organising the switch? ;)
Just on my part/preference...

Git lacks GUI, bzr is a bit behind on GUI but catching up, SVN is
decent. Not great but decent.

Git does the job it's designed for very well, but for many people
it's not the best approach. I jump between GUI clients and command-
line. On Windows I'd use TkCVS, TortoiseCVS, and command-line CVS
together, and for different aspects. With SVN I use command-line and
TkSVN.

Lack of Bzr integration to Eclipse was the last main negative I saw
on it. SVN integration was ok, but slowed.

I've also done a survey of systems recently for other reasons, and
Bzr seems to be closest to getting better than SVN.

One main drawback I find with SVN is its lack of tagging. The switch
to SVN, in fact, caught me just when I was trying to add tagging to
branch merges to get nice history, but SVN can't handle that. :-(

http://www.twobarleycorns.net/tkcvs/screen-branch.html


I'd definitely want to be sure we'd not hit any other hidden
limitations like SVN's lack of tagging.

Now if only Git or bzr had a GUI like Perforce's... :-)
Peter Moulder
2008-03-15 07:09:49 UTC
Permalink
Post by jiho
I'm not sure there's really a need to continue counting points right
now. It seems bazaar is the clear winner.
I've been composing the below before the above was posted.

Looking at
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software,
there is one startling difference among git,hg,bzr: it is stated that
bzr cannot do end-of-line conversions, i.e. cannot adapt the end
of line characters for text files such that they match the end of line
style for the operating system under which it is used.
(Status: http://bazaar-vcs.org/LineEndings)

I wonder how much of an issue this is; could it actually be fatal for
what is otherwise a very promising alternative? Let's look at how we
would address this issue if we were to choose bzr.

If a commit includes a change that adds or removes CR to/from the end of
each line, then it tends to make it awkward to merge changes for other
people (at least in most systems, I suppose in bzr too). Thus, it would
be nice if we could ensure that the "right" line endings are in use at
commit time (converting or refusing to commit rather than committing the
wrong thing) so that we never have commits that change the line endings
in the repository version of the file. The checkeol plugin
(http://bazaar.launchpad.net/~bialix/+junk/checkeol) promises to do
this. How does one set it up -- can we make it enforce our chosen line
ending convention for new files, or will it only check that existing
files keep their existing line ending convention? If checkeol works
well then we just need to decide what the "right" line ending is for
each file type, and hope we never need to change our mind.

One issue is that, for traditional Unix tools, backslash-CR-LF means
something quite different from backslash-LF. I've just tested: DOS line
endings work fine for g++ and gnu make 3.81 (though I seem to recall
that earlier versions didn't accept DOS line endings for backslash
purposes), but not for shell script (either dash or bash).

It's been a while since I've used cygwin, but I believe that cygwin
slightly prefers Unix line endings: that Unix line endings always work,
while cygwin can be configured to allow DOS line endings.

So at least for shell scripts, we want Unix line endings.

I believe that all popular editors on both Un*x, MacOS and Windows will
happily edit files regardless of their line-ending convention,
preserving that convention for lines added; except that the ever-present
Windows Notepad requires DOS line endings. (Notepad isn't a programming
editor, it's just the default text file editor, and I've come across
people editing source files with it.) My information is rather dated,
though. (Does the default text editor in Windows still not play well
with Unix line endings?) Can anyone name other popular editors that
don't work well with non-native line endings? vi other than vim don't
handle non-Unix line endings, though I don't know if any Inkscape
developers would use vi other than vim; solaris users perhaps?

The main annoyance regardless of platform (depending on whether checkeol
converts or merely warns) is when adding files, particularly when adding
a large number of files. Tools like fromdos/todos will help, once
installed. (Extra barrier for Inkscape development participation.)

Does anyone feel like advancing the state of this feature in bzr ?

Otherwise, what convention would we choose for text files other than
shell scripts? READMEs I really don't care one way or another. C++
source code I hope we go with Unix [no doubt influenced by my being a
Un*x user] but can see arguments for choosing DOS line endings.

pjrm.
MenTaLguY
2008-03-15 21:15:33 UTC
Permalink
Post by Peter Moulder
Post by jiho
I'm not sure there's really a need to continue counting points right
now. It seems bazaar is the clear winner.
I've been composing the below before the above was posted.
Looking at
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software,
there is one startling difference among git,hg,bzr: it is stated that
bzr cannot do end-of-line conversions, i.e. cannot adapt the end
of line characters for text files such that they match the end of line
style for the operating system under which it is used.
(Status: http://bazaar-vcs.org/LineEndings)
I've never seen this sort of feature work out well in practice.
Invariably, binary files get marked as text or vice-versa. I've seen
way too many problems over the years with files getting erroneously
marked as "binary" or "text" when they weren't.

As far as I know, it's also not a feature we've been using in
Subversion.

-mental
j***@joncruz.org
2008-03-15 21:56:38 UTC
Permalink
Post by MenTaLguY
Post by Peter Moulder
Post by jiho
I'm not sure there's really a need to continue counting points right
now. It seems bazaar is the clear winner.
I've been composing the below before the above was posted.
Looking at
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software,
there is one startling difference among git,hg,bzr: it is stated that
bzr cannot do end-of-line conversions, i.e. cannot adapt the end
of line characters for text files such that they match the end of line
style for the operating system under which it is used.
(Status: http://bazaar-vcs.org/LineEndings)
I've never seen this sort of feature work out well in practice.
Invariably, binary files get marked as text or vice-versa. I've seen
way too many problems over the years with files getting erroneously
marked as "binary" or "text" when they weren't.
As far as I know, it's also not a feature we've been using in
Subversion.
Eeeeek!!!!

As far as I know, it's a feature we've used in *all* source control software.
Even when I was using RCS only it would do the proper thing. If I check out
onto a linux box, I get LF. If I check out on a Windows box I get CR-LF.

Does Bazaar really not do this?!?!?!?!
Terry Brown
2008-03-15 23:22:25 UTC
Permalink
On Sat, 15 Mar 2008 18:56:38 -0300
Post by j***@joncruz.org
As far as I know, it's a feature we've used in *all* source control
software. Even when I was using RCS only it would do the proper
thing. If I check out onto a linux box, I get LF. If I check out on a
Windows box I get CR-LF.
Does Bazaar really not do this?!?!?!?!
It really does not - I do some stuff on another project which just
switched, and ran into this. I think, not sure, that pre/post
checkin/out filters in bzr aren't mature / implemented yet but could in
theory be used.

However, the bzr belief, which I think probably holds true most of the
time, is that most good editors will handle the various conventions
transparently, so it's not an issue.

Of course the project I referred to above, the leo python editor /
hierarchical data manager, doesn't transparently handle the eols, for
fairly good reasons (it's not really a text editor).

I wrote a small python script that compares the working copy text file
eols with the last committed version and offers to adjust to working
copy versions to match, running this before diffing or committing works
well for me.

Cheers -Terry
j***@joncruz.org
2008-03-16 00:16:36 UTC
Permalink
Post by Terry Brown
However, the bzr belief, which I think probably holds true most of the
time, is that most good editors will handle the various conventions
transparently, so it's not an issue.
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!

My ...mumble...mumble... years of experience in the software field has shown the
exact opposite.

While some editors deal with confused users decently, most do not. Especially
since it's hard to know in which way users are not doing things well. MS's
DevStudio is one of the worst for mixing line-ends, but others do it too.

Usually this will show up when someone spends lots of time tracking down weird
bugs only to find out a line-end change messed up a macro with a continuation
char at the end... things like that.


Even with SVN and such I've had to clean things up in Inkscape code now and
then. Someone will check out and dev on one box, then check in from another.
Often with Samba mounts or shared USB drives involved. Wreaks havoc with diffs
and file history among other problems.

(then again if one never looks at file history and diffs, then one might never
see a 'problem')
Peter Moulder
2008-03-16 06:38:45 UTC
Permalink
As far as I know, it's [...] not a feature we've been using in
Subversion.
We have indeed been using it in subversion. Though we haven't had it
set up to be added to new files automatically, so for example I see that
the newly-added src/bind subtree doesn't use the feature. In the past, I've
occasionally manually enabled the feature on new files (r1623{5,6,7},
r16085, r16043, r11156, r11011 according to svn log).
I've never seen this sort of feature work out well in practice.
Invariably, binary files get marked as text or vice-versa. I've seen
way too many problems over the years with files getting erroneously
marked as "binary" or "text" when they weren't.
I have a feeling that svn handles it better than CVS, though I don't
recall what the difference is. Maybe svn is better at guessing which
files are binary. The absence of default keyword substitution can't
hurt.

In most cases, problems can be fixed after the fact just by changing how
the file is marked.

I agree that differing line-ending conventions are a source of pain, but
I'm not sure that witholding conversion is the best way of avoiding
pain: that option tends to leave inkscape with some files using CR-LF
and some files using LF, and revisions that include changing the
line-ending format of existing lines (which makes merging a pain).

Thus, if we are to choose bzr, then I believe we want to decide what
line-ending convention to use for each type of text file, and use an
automated commit-time check to enforce that convention.

Or we work on bzr to support an equivalent of svn's svn:eol-style
property. Or we choose a DVCS other than bzr.

pjrm.
Bob Jamison
2008-03-16 11:56:47 UTC
Permalink
Hi!

Yes, and I have noticed that there is a certain "stickiness," in that if
a file is initially added with dos line endings, SVN (at least mine)
tends to keep it that way.

Some of the files in question are the svg/smil/views/css/stylesheets
"semi-official" Java interfaces classes from w3c.org's site. I've noticed
that at least the svg set of original files had dos line endings, so
I've run
dos2unix on the entire directory.

Maybe people would like to give this a try, as an experiment:

find . -print -exec dos2unix --safe {} \;


Tho, if svn considers -every- line different, it could cause transmission
of the entire file.


bob
Post by Peter Moulder
We have indeed been using it in subversion. Though we haven't had it
set up to be added to new files automatically, so for example I see that
the newly-added src/bind subtree doesn't use the feature. In the past, I've
occasionally manually enabled the feature on new files (r1623{5,6,7},
r16085, r16043, r11156, r11011 according to svn log).
jiho
2008-03-16 14:52:50 UTC
Permalink
Post by Peter Moulder
Post by jiho
I'm not sure there's really a need to continue counting points right
now. It seems bazaar is the clear winner.
I've been composing the below before the above was posted.
Looking at
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software,
there is one startling difference among git,hg,bzr: it is stated that
bzr cannot do end-of-line conversions, i.e. cannot adapt the end
of line characters for text files such that they match the end of line
style for the operating system under which it is used.
(Status: http://bazaar-vcs.org/LineEndings)
I wonder how much of an issue this is; could it actually be fatal for
what is otherwise a very promising alternative? Let's look at how we
would address this issue if we were to choose bzr.
OK, let's start counting again then. I removed mercurial since no one
really stepped up to give advice on it. Right now it seems that both
solution have different flaws. However git ones seems to be just a
matter of changing habits (e.g. rely more on the command line, learn a
few new commands), while on the other hand bazzar would be more
enjoyable to use but has some more "deep" flaws (e.g. line endings and
slowness).

-- GIT ----------------------------
+ faster:
. local commits: <1s vs 4s
. push a new branch: instantaneous vs 35 min
+ ability to follow chunk of codes around, without relying on file
names. Probably useful from a refactoring point of view
+ probably the fastest growing user base => many tools
+ TextMate bundle

- git is designed with the Linux kernel's hierarchical workflow in
mind (few 'push'ers to the central repos), so may require alteration
in how Inkscape's workflow works (any dev can commit)
- we would need to set up and administer this ourselves
- revisions are indicated with SHA's rather than numbers
- commands dissimilar to what we're used to with svn (e.g., no 'git
update')
- have to git add all modified files before committing them (or resort
to a non specific commit -a)
- no decent GUI (for windows?)

-- BZR ----------------------------
+ already integrated in launchpad http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.html
. Associating branches to bugs
. Associating branches to blueprints
. Changes state of bugs in LP when committing in Bazaar
. Web interface for creating branches quickly and easily
+ supports renames (could be considered a - by git users)
+ supports bundling changesets
+ tortoiseBZR
+ Fewer commands - makes it easier to learn
+ Supports multiple workflows, including what we use for Inkscape (See http://bazaar-vcs.org/Workflows)
+ Easy administration. Mostly done through Launchpad, plus Bzr folks
are available to help.

- no support for line-endings conversion/convention enforcing (but
such systems may create the risk of wrongly recognizing binary files)

JiHO
---
http://jo.irisson.free.fr/
Bob Jamison
2008-03-16 16:54:55 UTC
Permalink
Well, for a thread that's only 3 days old...

I for one use Mercurial on a daily basis, and think that it's
wonderful. :-)


bob
Post by jiho
I'm not sure there's really a need to continue counting points right
jiho
2008-03-16 17:16:53 UTC
Permalink
Post by Bob Jamison
Well, for a thread that's only 3 days old...
I for one use Mercurial on a daily basis, and think that it's
wonderful. :-)
Great! could you please add some + (and maybe also - ) in the list
below for mercurial then?

I concluded this a bit fast indeed. But even in three days there were
already so many messages in favour of bzr that it looked hopeless for
anything else to catch up. It seems things in fact more balanced right
now.

-- GIT ----------------------------
+ faster:
. local commits: <1s vs 4s
. push a new branch: instantaneous vs 35 min
+ ability to follow chunk of codes around, without relying on file
names. Probably useful from a refactoring point of view
+ probably the fastest growing user base => many tools
+ TextMate bundle

- git is designed with the Linux kernel's hierarchical workflow in
mind (few 'push'ers to the central repos), so may require alteration
in how Inkscape's workflow works (any dev can commit)
- we would need to set up and administer this ourselves
- revisions are indicated with SHA's rather than numbers
- commands dissimilar to what we're used to with svn (e.g., no 'git
update')
- have to git add all modified files before committing them (or resort
to a non specific commit -a)
- no decent GUI (for windows?)

-- HG -----------------------------
+ tortoiseHG
+ TextMate bundle


-- BZR ----------------------------
+ already integrated in launchpad http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.html
. Associating branches to bugs
. Associating branches to blueprints
. Changes state of bugs in LP when committing in Bazaar
. Web interface for creating branches quickly and easily
+ supports renames (could be considered a - by git users)
+ supports bundling changesets
+ tortoiseBZR
+ Fewer commands - makes it easier to learn
+ Supports multiple workflows, including what we use for Inkscape (See http://bazaar-vcs.org/Workflows)
+ Easy administration. Mostly done through Launchpad, plus Bzr folks
are available to help.

- no support for line-endings conversion/convention enforcing (but
such systems may create the risk of wrongly recognizing binary files)

JiHO
---
http://jo.irisson.free.fr/
MilesTogoe
2008-03-17 08:41:20 UTC
Permalink
Post by jiho
Post by Bob Jamison
Well, for a thread that's only 3 days old...
I for one use Mercurial on a daily basis, and think that it's
wonderful. :-)
Great! could you please add some + (and maybe also - ) in the list
below for mercurial then?
I concluded this a bit fast indeed. But even in three days there were
already so many messages in favour of bzr that it looked hopeless for
anything else to catch up. It seems things in fact more balanced right
now.
-- GIT ----------------------------
. local commits: <1s vs 4s
. push a new branch: instantaneous vs 35 min
+ ability to follow chunk of codes around, without relying on file
names. Probably useful from a refactoring point of view
+ probably the fastest growing user base => many tools
+ TextMate bundle
- git is designed with the Linux kernel's hierarchical workflow in
mind (few 'push'ers to the central repos), so may require alteration
in how Inkscape's workflow works (any dev can commit)
- we would need to set up and administer this ourselves
- revisions are indicated with SHA's rather than numbers
- commands dissimilar to what we're used to with svn (e.g., no 'git
update')
- have to git add all modified files before committing them (or resort
to a non specific commit -a)
- no decent GUI (for windows?)
-- HG -----------------------------
+ tortoiseHG
+ TextMate bundle
-- BZR ----------------------------
+ already integrated in launchpad http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.html
. Associating branches to bugs
. Associating branches to blueprints
. Changes state of bugs in LP when committing in Bazaar
. Web interface for creating branches quickly and easily
+ supports renames (could be considered a - by git users)
+ supports bundling changesets
+ tortoiseBZR
+ Fewer commands - makes it easier to learn
+ Supports multiple workflows, including what we use for Inkscape (See http://bazaar-vcs.org/Workflows)
+ Easy administration. Mostly done through Launchpad, plus Bzr folks
are available to help.
- no support for line-endings conversion/convention enforcing (but
such systems may create the risk of wrongly recognizing binary files)
Now that some other significant open source projects are using DVCS -
maybe it would be good to get an opinion from each as to how they like it.
Mercurial(hg) - mozilla
Git - linux kernel team
Bzr - canonical, webpy
I'm sure there are other projects for each.

Also, maybe DVCS can help allow more testing on commits - frequent
commits to local machine does not have to be slowed with extensive tests
but less frequent merges can have more time consuming tests run on the
commits which can help eliminate break the build commit errors,
especially on other OS's than the person committing is on.

attached is some feedback from webpy (bzr)
Post by jiho
Post by Bob Jamison
The Inkscape team is evaluating using a dvcs. Noticed the webpy
development branch is using Bazaar for version control - is everyone
happy with it ? is checkout and merging speed okay ?
I am happy with it because
1. it is intutive
2. good launchpad integration
3. easy to host
I have used mercurial, but I don't like its way of managing branches.
It keeps all branches in the same tree, whereas bzr keeps each branch
in a separate tree, which I found very convenient.
But the speed is a bit disappointing. If you want speed, try git.
Peter Moulder
2008-03-17 10:07:07 UTC
Permalink
Post by MilesTogoe
Now that some other significant open source projects are using DVCS -
maybe it would be good to get an opinion from each as to how they like it.
Mercurial(hg) - mozilla
Git - linux kernel team
Bzr - canonical, webpy
I'm sure there are other projects for each.
According to
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software,
some users are:

bzr: Ubuntu, Launchpad, Drupal (but for main repository CVS still used),
KatchTV
git: Linux kernel, Cairo, ELinks, Wine, X.Org, XCB, XMMS2, Compiz Fusion,
Samba, OLPC core development
hg: e2fsprogs, Mozilla, NetBeans, Xine, Xen, OpenJDK, OpenSolaris, wmii,
MoinMoin, Linux-HA

Carl Worth of Cairo is sometimes around #inkscape or related channels,
so someone could ask him and post the results here. I'll be meeting
with someone from Mozilla in about three weeks if that's any help.


Incidentally, other options are for us to make expanded use of git-svn
or bzr-svn or the like (with help from existing users), as a way of
getting more experience with those, and some of the benefits of a
complete switch, while allowing more time either to hear of others'
experiences and/or to see if any of the contenders improves to become a
clear winner. (I'm not necessarily advocating this, I'm just saying
it's an option, and one we can discard whenever we want if we do
consciously adopt it.)

pjrm.
John Bintz
2008-03-14 12:41:28 UTC
Permalink
Post by Bryce Harrington
What will the codebase cleanup work entail? The work will range from
straightforward "grunt" work like making some simple code changes to all
files in the codebase, to meatier work like abstracting widely used code
into a more concise and powerful algorithm, to advanced work such as
extracting distinct code into independent code packages.
I briefly mentioned this tool on chat, but I figured I'd throw it on the
list for everyone to take a look at (and I'll add it to the wiki later):

http://pmd.sourceforge.net/cpd.html

I've run the current Inkscape codebase through the Copy/Paste Detector
and found plenty of duplicated code that, at the very least, can be
refactored to look nice and reduce the SLOC count. I've already done a
little of this in pen-context.cpp, and plan on tackling some of the
parts of the livarot code and some of the dialog code that look ripe for
easy refactoring.

John
Bryce Harrington
2008-03-14 18:29:45 UTC
Permalink
Post by John Bintz
Post by Bryce Harrington
What will the codebase cleanup work entail? The work will range from
straightforward "grunt" work like making some simple code changes to all
files in the codebase, to meatier work like abstracting widely used code
into a more concise and powerful algorithm, to advanced work such as
extracting distinct code into independent code packages.
I briefly mentioned this tool on chat, but I figured I'd throw it on the
http://pmd.sourceforge.net/cpd.html
Looks like this is in the roadmap. I think it's a good idea.

Note that we may also have "duplicate" code in terms of functionality,
which is not cut/paste, but rather reimplementation of the same
essential functionality (cxxtest and utest as a case in point.) I'm not
sure that CPD would detect such cases, so while that may catch a lot of
the more egregious cases, we need to not assume it will solve the issue
100%.

Bryce
bulia byak
2008-03-14 18:30:40 UTC
Permalink
On Fri, Mar 14, 2008 at 9:41 AM, John Bintz
Post by John Bintz
I've run the current Inkscape codebase through the Copy/Paste Detector
and found plenty of duplicated code that, at the very least, can be
refactored to look nice and reduce the SLOC count. I've already done a
little of this in pen-context.cpp, and plan on tackling some of the
parts of the livarot code and some of the dialog code that look ripe for
easy refactoring.
I don't think it's worth it to spend resources on livarot - eventually
it's going to be replaced by cairo and 2geom.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
j***@coswellproductions.org
2008-03-14 18:35:58 UTC
Permalink
Post by bulia byak
I don't think it's worth it to spend resources on livarot - eventually
it's going to be replaced by cairo and 2geom.
Sounds good to me. :) I'll start with just the dialog code, then.

Thanks,

John
Mihaela
2008-03-14 19:40:38 UTC
Permalink
Post by Bryce Harrington
What will the codebase cleanup work entail? The work will range from
straightforward "grunt" work like making some simple code changes to all
files in the codebase, to meatier work like abstracting widely used code
into a more concise and powerful algorithm, to advanced work such as
extracting distinct code into independent code packages.
0. Complete some of the big architectural refactoring efforts
1. Reduce source code line count
2. Break useful code out into stand-alone libraries
3. Increase code stylistic consistency
4. Make the codebase more convenient to code in
Does this also mean keeping multithreading in mind?
https://bugs.launchpad.net/inkscape/+bug/200415

Multithreading and even distributed computing seem to be the future,
something Inkscape will face sooner or later. Since cleanup will be done
now it seems natural to incorporate it into the plan (sooner).

If it enters the plan I may be able to bribe a guy who's experienced in
that field to help :)
Bryce Harrington
2008-03-15 05:13:53 UTC
Permalink
Post by Mihaela
Post by Bryce Harrington
What will the codebase cleanup work entail? The work will range from
straightforward "grunt" work like making some simple code changes to all
files in the codebase, to meatier work like abstracting widely used code
into a more concise and powerful algorithm, to advanced work such as
extracting distinct code into independent code packages.
0. Complete some of the big architectural refactoring efforts
1. Reduce source code line count
2. Break useful code out into stand-alone libraries
3. Increase code stylistic consistency
4. Make the codebase more convenient to code in
Does this also mean keeping multithreading in mind?
https://bugs.launchpad.net/inkscape/+bug/200415
Multithreading and even distributed computing seem to be the future,
something Inkscape will face sooner or later. Since cleanup will be done
now it seems natural to incorporate it into the plan (sooner).
Good point; yes this has come up in the past and iirc the conclusion was
always that some significant refactoring would be needed to bring the
code closer to being able to run in a threaded fashion. I don't recall
specifics, but if we could take steps to close that gap, it could make
it more feasible to achieve. Mental - any thoughts here?
Post by Mihaela
If it enters the plan I may be able to bribe a guy who's experienced in
that field to help :)
Sure, even if just to provide some review and advice, it'd be
appreciated.

Bryce
MenTaLguY
2008-03-15 21:09:35 UTC
Permalink
Post by Bryce Harrington
Post by Mihaela
Multithreading and even distributed computing seem to be the future,
something Inkscape will face sooner or later. Since cleanup will be done
now it seems natural to incorporate it into the plan (sooner).
Good point; yes this has come up in the past and iirc the conclusion was
always that some significant refactoring would be needed to bring the
code closer to being able to run in a threaded fashion. I don't recall
specifics, but if we could take steps to close that gap, it could make
it more feasible to achieve. Mental - any thoughts here?
The main thing is eliminating tight coupling between subsystems, after
which point we can make individual subsystems threaded/threadsafe.

There are some secondary concerns with libraries as well; for example
libgc does not work well with threads that were not created via its
thread wrappers. The upcoming version of libgc (7.2?) will have some
additional thread registration functions which can be used to address
that issue, but it's not released yet and even once it is it'll be a
while before it hits distributions.

-mental
j***@joncruz.org
2008-03-15 22:07:14 UTC
Permalink
Post by MenTaLguY
There are some secondary concerns with libraries as well; for example
libgc does not work well with threads that were not created via its
thread wrappers. The upcoming version of libgc (7.2?) will have some
additional thread registration functions which can be used to address
that issue, but it's not released yet and even once it is it'll be a
while before it hits distributions.
Yes, libraries might give us some unexpected problems. Just in adding the newer
tablet support I happened to run across all sorts of things that are in the gtk
or gdk headers that appear to be disabled for thread-safe builds.

(I'm hoping that is just legacy defines... but it may be a lurking problem)
MenTaLguY
2008-03-15 21:01:09 UTC
Permalink
Post by Mihaela
Multithreading and even distributed computing seem to be the future,
something Inkscape will face sooner or later. Since cleanup will be done
now it seems natural to incorporate it into the plan (sooner).
It's just not feasible right now. We need to clean up the design and
partition things a lot better, so we could make individual portions of
the codebase threadsafe. Right now, everything touches everything else,
and nothing is threadsafe.

-mental
Mihaela
2008-03-16 18:31:26 UTC
Permalink
Post by MenTaLguY
Post by Mihaela
Multithreading and even distributed computing seem to be the future,
something Inkscape will face sooner or later. Since cleanup will be done
now it seems natural to incorporate it into the plan (sooner).
It's just not feasible right now. We need to clean up the design and
partition things a lot better, so we could make individual portions of
the codebase threadsafe. Right now, everything touches everything else,
and nothing is threadsafe.
The main thing is eliminating tight coupling between subsystems, after
which point we can make individual subsystems threaded/threadsafe.
-mental
Yes, separating parts of code into pieces that are as independent as
possible is the ground work for multithreading. Isn't that what 0.47
cleanup will (try to) encompass?

There's a thing about multiprocessing to keep in mind here; you don't
need to have your entire code cleaned up and threadsafe. I think its
fair to say no software can, you always have parts that can be split to
work on more than one core, and parts that can't (this part can even be
tangled spaghetti code).

It would be worthwhile to analyze the code and see what parts are
appropriate for multithreading. Maybe you would only find 2 or 3 such
places, but the speed increase on multicore machines could still be very
significant.

The expert in multithreading I mentioned might help isnt familiar with
Inkscape code and he'd need your input when it came to a specific case,
but he thinks that heavy load code segments are potentially the best
candidates for multicore implementation:

1. places with large loops
2. heavy maths formulas (matrix included)
3. graphics rendering (depending on its multithreading features)

Some of it will be a complex job, but its inevitable, it must be done
and it definitely can be done, with a little bit of lateral thinking and
a little bit of effort. As I mentioned before there are many levels of
parallelization, it all depends on your features and code design.

In the new version of gcc OpenMP will be implemented (i think its in
experimental phase now). With it the parallelization will be much
easier, so it would also be very good to implement OpenMP into Inkscape.

If youd be able to find those heavy load segments and apply OpenMP on
them, that would be HUGE progress.

The articles on the Intel site are good, you can check it out if you
like http://softwarecommunity.intel.com/isn/home/MultiCore.aspx
Post by MenTaLguY
Yes, libraries might give us some unexpected problems. Just in adding the newer
tablet support I happened to run across all sorts of things that are in the gtk
or gdk headers that appear to be disabled for thread-safe builds.
(I'm hoping that is just legacy defines... but it may be a lurking problem)
Yes this problem needs to be addressed but its not a show stopper; one
of the methods you can apply here is to lock the not_thread_safe library
so that only one thread can access it.

Anyway, no matter when multicore/distributed processing actually gets
implemented, it would be wise to start *planning* for it as soon as
possible. As you all know making code threadsafe will only become more
complicated as the code gets bigger.
MenTaLguY
2008-03-17 00:08:03 UTC
Permalink
I think its fair to say no software can, you always have parts that
can be split to work on more than one core, and parts that can't
(this part can even be tangled spaghetti code).
There's still the infrastructural issues; for example, we have to be
careful about libgc until we can rely on the new versions with better
thread support being widely available.
It would be worthwhile to analyze the code and see what parts are
appropriate for multithreading. Maybe you would only find 2 or 3 such
places, but the speed increase on multicore machines could still be very
significant.
I've done this to an extent, actually. The biggest potential win would
be rendering, although we have to be careful since once we start taking
advantage of hardware acceleration, rendering becomes more of an IO
issue rather than a computation one. (more threads tends to make IO
worse rather than better, since you saturate your IO bandwidth quickly
and start to take hits from multiplexing)

The biggest problem right now is that the rendering/arena code reaches
up vertically through nearly every Inkscape subsystem, in large part via
its dependency on SPStyle. Until we break that dependency, I don't have
much hope about parallelizing rendering generally. The exception may be
the rendering of SVG filter effects, the inner loops of which are
relatively isolated from the rest of the code. Filter effects are also
the least likely to get hardware acceleration anytime soon, so we don't
have to worry about that complication either.

Most of the rest of the codebase isn't really going to parallelize well,
ever; a lot of things like document operations and transactions are
rather inherently serial. The performance problems there are also often
more a matter of doing too much unnecessary work than anything else.

A few threads could be applied to improve UI responsiveness, and I'd
eventually like to do that, but we'd need to be very cautious about
non-determinism. We've already had some very nasty problems from
non-determinism introduced by people naively using Glib idle tasks or
calling back into the event loop from an event handler; threads would be
several orders of magnitude worse in that respect.
The expert in multithreading I mentioned might help isnt familiar with
Inkscape code and he'd need your input when it came to a specific case,
Could you bring him into the thread, maybe?
In the new version of gcc OpenMP will be implemented (i think its in
experimental phase now). With it the parallelization will be much
easier, so it would also be very good to implement OpenMP into
Inkscape.
I believe gcc has had some OpenMP support in released versions since
4.2. OpenMP is rather limited in what it can do for us, but it should
be helpful for optimizing some computation-heavy loops (filter effects
again?). Generally I would like to try to avoid the use of explicit
threading when possible, and OpenMP certainly fits that bill.

-mental
Ted Gould
2008-03-17 18:14:03 UTC
Permalink
Post by MenTaLguY
Post by Mihaela
In the new version of gcc OpenMP will be implemented (i think its in
experimental phase now). With it the parallelization will be much
easier, so it would also be very good to implement OpenMP into Inkscape.
I believe gcc has had some OpenMP support in released versions since
4.2. OpenMP is rather limited in what it can do for us, but it should
be helpful for optimizing some computation-heavy loops (filter effects
again?). Generally I would like to try to avoid the use of explicit
threading when possible, and OpenMP certainly fits that bill.
I'm curious if we wouldn't get more gain out of using something like
liboil in these cases. The reality is that our filters are rather small
overall. Probably something like MMX would get bigger gains that
full-scale multiprocessing until we can go "full-multithreaded" across
the codebase.

--Ted
MenTaLguY
2008-03-17 20:39:27 UTC
Permalink
Post by Ted Gould
Post by MenTaLguY
I believe gcc has had some OpenMP support in released versions since
4.2. OpenMP is rather limited in what it can do for us, but it should
be helpful for optimizing some computation-heavy loops (filter effects
again?). Generally I would like to try to avoid the use of explicit
threading when possible, and OpenMP certainly fits that bill.
I'm curious if we wouldn't get more gain out of using something like
liboil in these cases. The reality is that our filters are rather small
overall. Probably something like MMX would get bigger gains that
full-scale multiprocessing until we can go "full-multithreaded" across
the codebase.
I think OpenMP and liboil would be complimentary in this case, and filter
rendering times are in fact a major pain point for users.

-mental
Loading...