Hi all,
even though my work on Inkscape has been very limited since we
switched version control systems, I must say that the few times I had
to work with bzr weren't the most fun of experiences either, to say
the least. I admit that I am a heavy git user and that therefore I am
cetrainly biased in my view, but even with my few commits to the
Inkscape trunk I have seen most of the problems other people mentioned
(most notably, slowness, broken repositories after trying a pull or
merge, and just generally bzr often getting in the way of what I tried
to do or it being unintuitive).
I definitely don't want to start a flame war, and I'm not sure if we
want to consider switching to another VCS again in the near future.
But if we are willing to start a discussion (which seems to be
happening anyway), I would certainly like to make a plea for git
again. I know that many people who haven't tried it are a bit worried
because for some reason it still has a reputation of being somewhat
complicated, but I honestly think that this is not a valid point any
more. It has evolved a lot, there is excellent documentation out
there, it is extremely fast, very reliable and flexible, can be used
for any kind of workflow (from the SVN-like to the most heavily
distributed), has nice repository browsers, there seem to be decent
GUIs around (although I have never tried them), and it is virtually
impossible to break anything.
As Alexandre said, I believe that with GSoC and whatnot the ability to
work in branches is essential, so switching back to SVN is not really
an option IMHO, whereas git supports very cheap branching/switching
between branches (telling from my little exprience with bzr and hg,
git is vastly superior when it comes to handling branches, which might
even encourage more people to explore the work done in the GSoC
branches, say, which didn't seem to happen much in the past). If I
remember correctly, one of the major arguments against git was the
lack of support for Windows. A quick Google search seems to suggest
that this situation has changed quite a bit, though. If we consider
reopening the discussion, I am even willing to start using Windows for
the first time in years :) in order to investigate this a bit further.
I would also offer to come up with instructions for how to use git
that fit the workflows of our main developers. It may well turn out
that the windows interface is not good enough (e.g. similiar to
tortoisebzr, which apparently looked nice but according to Johan
doesn't come close to tortoisesvn) and that there are other issues
that may prevent us from going down the git route, but my feeling is
that it would be worth giving it a shot.
In lieu of a P.S.: I drafted this email a couple of days ago but
didn't get around to finishing and sending it. On second thought and
after reading a few of the emails that have arrived in the meantime, I
might have got carried away a bit due to my recent experiences with
other DVCS, none of which has come anywhere near the pleasure I have
had in working with git. But for Inkscape it probably makes sense to
first explore if we can get bzr to work for us (although I'm not sure
this will be possible given that many complaints seem to be targeted
against somewhat inherent problems). But if we should start discussing
other options again, my points and offers above still stand.
Cheers,
Max
2011/2/5 John Cliff <john.cliff@...>:
> I honestly couldn't care less if it's distributed or not, it's that it just doesn't work very well that was the issue.
> (and yes, I'm bundling tortoise & bzr together, I had a working interface on win before, I don't anymore)
> To use your example, the parking brake sticks and the gearbox randomly changes back to first when your doing 60.
>
> Sent from my iPhone
>
> On 5 Feb 2011, at 05:05, Josh Andler <scislac@...> wrote:
>
>> On Fri, Feb 4, 2011 at 8:47 PM, Alexandre Prokoudine
>> <alexandre.prokoudine@...> wrote:
>>> On 2/5/11, bulia byak wrote:
>>>
>>>> Distributed VCSes have their place in projects where a lot of forking
>>>> and merging happens, or where all developers are comfortable with that
>>>> model and newbies are not welcome (such as Linux kernel). But Inkscape
>>>> is not like that at all - it has traditionally preferred gradual
>>>> in-the-trunk reworking rather than branches even for complex
>>>> refactorings, and while it is complex it has a lot of places that are
>>>> newbie-hackable to great benefit and with little danger (such as
>>>> filters).
>>>
>>> With all respect due, our primary tradition these days seems to be in
>>> the lines of "can we pretty please try to release this year?". What
>>> you are referring to stopped taking place years ago. Since 2007 or so
>>> half of our new features come from GSoC projects that live in branches
>>> first and get merged later. There's no rule for things happening any
>>> more.
>>>
>>> IMO, there's nothing bad about working in branches as long as trunk
>>> doesn't undergo any major infrastructure changes and as long as there
>>> are people who are willing to do QA before merging stuff from
>>> branches.
>>>
>>> Actually, even major changes in trunk (or master, in case of Git) are
>>> not exactly such a pain.
>>> I never tried merging from trunk into local clone in bzr, buit I did
>>> it once or twice with Git, and it wasn't such a big deal.
>>
>> Am I the only one who just views the dvcs model as the norm? It seems
>> like more than half of the projects I checkout and compile from are
>> using either bzr or git... given that my contributions to said
>> projects tend to be very minimal, but it just doesn't seem as nasty as
>> a lot of people seem to experience. Doing a pull/update prior to
>> starting a commit process just seems like the normal procedure. To me
>> it's much like turning on the ignition to the car, releasing the
>> parking brake if on a hill, placing my foot on the brake, and changing
>> to a gear from park. It doesn't take long before it becomes routine.
>>
>> Cheers,
>> Josh
>>
>> ------------------------------------------------------------------------------
>> The modern datacenter depends on network connectivity to access resources
>> and provide services. The best practices for maximizing a physical server's
>> connectivity to a physical network are well understood - see how these
>> rules translate into the virtual world?
>> http://p.sf.net/sfu/oracle-sfdevnlfb
>> _______________________________________________
>> Inkscape-devel mailing list
>> Inkscape-devel@...
>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>
|
