svn's branch-merge to mitigate deps; cairo, gtkmm 'trainwreck'

First, my sincere thanks to the Inkscape developers. You've developed a remarkable program in a very short time. The future ubiquity of SVG on several platforms owes a huge debt of gratitude to Inkscape and the people behind it.
I noted the recent concern about which versions of various libraries (gtkmm, etc.) Inkscape should target for maximum benefit. See "newest gtkmm needed to compile HEAD" and "train wreck...") As a Gentoo user (i.e. self-imposer of trainwrecks), I periodically compile Inkscape-cvs against very recent gtk gtkmm, cairo etc. Anything older than the latest Ubuntu seems positively fossilized to my biased point of view.
When I see mention of various cool features that developers have running in a private sandbox, I think it speaks to Inkscape's extreme need for a source repository that provides better support for branching and merging. I think Inkscape needs to migrate its source to subversion, and let the various devs maintain according to their interest: short-lived feature branches, long-lived maintenance branches, and convenient build bundles (svn:externals), to push the bleeding edge and still satisfy the slower pace of disto compatibility.
Inkscape has a primary role to play in the SVG revolution on the GNOME and KDE linux desktops; it can't afford to lag behind the recent graphics libraries on which Cairo is being developed. At the same time, Inkscape needs to build packages for distros (and platforms) in various degrees of stability and vintage.
Subversion could facilitate things the Inkscape developers are already trying to do. Using svn:externals, bundles could be maintained that would provide every conceivable combination of dependency, and a high probability of build success. A simple 'svn switch' would allow one to try out that latest cool feature mentioned one the mailing list, and come back to a safer branch without hassle if the feature isn't fully cooked.
Just my $0.02, Inkscape is an amazing program with equally admirable community effort behind it. Keep up the good work.

On Thu, Nov 10, 2005 at 11:16:02PM -0500, Jeff Kowalczyk wrote:
First, my sincere thanks to the Inkscape developers. You've developed a remarkable program in a very short time. The future ubiquity of SVG on several platforms owes a huge debt of gratitude to Inkscape and the people behind it.
:-)
I noted the recent concern about which versions of various libraries (gtkmm, etc.) Inkscape should target for maximum benefit. See "newest gtkmm needed to compile HEAD" and "train wreck...") As a Gentoo user (i.e. self-imposer of trainwrecks), I periodically compile Inkscape-cvs against very recent gtk gtkmm, cairo etc. Anything older than the latest Ubuntu seems positively fossilized to my biased point of view.
I think a number of us use gentoo/ubuntu/debian (I'm a gentoo user myself), so right there with ya. :-) But based on our experiences in the past when we've changed dependencies, there are still a lot of people who use legacy distros (even rpm-based ones) that will speak up if we change too aggressively. Not that this is bad, but it just jacks up the noise level on the list and the bug tracker for a while. ;-)
When I see mention of various cool features that developers have running in a private sandbox, I think it speaks to Inkscape's extreme need for a source repository that provides better support for branching and merging. I think Inkscape needs to migrate its source to subversion.
You're right, we should migrate to Subversion.
Would you be willing to help us in this by porting our CVS documentation to what its equivalent would be for svn?
(Obviously, this still leaves open the question of who could provide us with subversion hosting, but it'd be one less hurdle for us.)
Bryce

On Nov 10, 2005, at 10:28 PM, Bryce Harrington wrote:
On Thu, Nov 10, 2005 at 11:16:02PM -0500, Jeff Kowalczyk wrote:
When I see mention of various cool features that developers have running in a private sandbox, I think it speaks to Inkscape's extreme need for a source repository that provides better support for branching and merging. I think Inkscape needs to migrate its source to subversion.
You're right, we should migrate to Subversion.
Well, I'm not quite sure that it speaks to an extreme need. We do have branches and different CVS modules for working out in, but many different developers have different work-styles and some prefer to play around a bit before going to far. It might be like a change from QUERTY to Dvorak, where it's a incremental improvement instead of an order of magnitude or two (as the only quantitative study I found on that showed perhaps a 4% increase in efficiency gain)
Jeff, you might want to skim the archives to see what came up on this issue before. Migrating to Subversion might be nice for a few things, but it's not seriously blocking a lot of people.
Also, there are some issues about Subversion's use that tend to put a damper on major enthusiasm for it. A lot of it can be summed up in the general feel that Subversion is designed to push it's developers' work-style on everyone. There are some base assumptions of theirs that go counter to many things I like to do at times. (oh, and in addition to having used several different CM solutions over the years, I also worked at a CM company)
Anyway, it could be a net gain, but there are several problems that need ironing out before we could get the most benefit from it. (Even a tool that works as well as TkCVS does for me is a large item)

On Thu, Nov 10, 2005 at 11:07:57PM -0800, Jon A. Cruz wrote:
Well, I'm not quite sure that it speaks to an extreme need. We do have branches and different CVS modules for working out in, but many different developers have different work-styles and some prefer to play around a bit before going to far. It might be like a change from
It's true a lot of people have gotten used to CVS's way of doing things, and certainly it makes sense to stick with it for preventing having people forced to learn new things.
However, I've used a bunch of different scm's and while I still prefer CVS myself, I view subversion as a worthwhile conversion. First, it's similar enough to CVS that you won't be losing anything. Second, you gain the benefits that SVN provides. ;-)
There are several downsides to SVN but in my view they mostly boil down to provisioning. If we have someone to provide SVN service we're good, otherwise we have a host of issues.
Bryce

mental@...3... wrote:
Quoting Bryce Harrington <bryce@...961...>:
You're right, we should migrate to Subversion.
Not without SVK, please.
If I remember right, I thought you could run SVK on top of Subversion on a user by user basis. So if someone just wanted to use subversion, they could. While other users could be using SVK. My understanding is that you only need SVK to access the mirrored, or local repositories.
--Ted

Quoting Jeff Kowalczyk <jtk@...36...>:
When I see mention of various cool features that developers have running in a private sandbox, I think it speaks to Inkscape's extreme need for a source repository that provides better support for branching and merging.
FWIW, the last time I looked at SVN, in practice SVN's branches are even worse than CVS's.
http://moonbase.rydia.net/mental/blog/programming/subversion-tagging-blows.h...
If we went with SVN, we'd really want to use something like SVK atop it to make branches actually usable.
Personally though, my favorite SCM at the moment is git.
-mental

mental@...3... guardò:
FWIW, the last time I looked at SVN, in practice SVN's branches are even worse than CVS's.
http://moonbase.rydia.net/mental/blog/programming/subversion-tagging-blows.h...
If we went with SVN, we'd really want to use something like SVK atop it to make branches actually usable.
Personally though, my favorite SCM at the moment is git.
I've looked at Mercurial and have found it very nice. It is simple and it looks more refined than git, sharing with it a lot of the ideas. I use it for everything, even for my home dir... :)
participants (6)
-
unknown@example.com
-
Bryce Harrington
-
Emanuele Aina
-
Jeff Kowalczyk
-
Jon A. Cruz
-
Ted Gould