...

On 3/2/11 21:57, Krzysztof Kosiński wrote:

...

2011/2/3 ~suv <suv-sf@...58...>:

...

There seem still some files missing (or need to be added to 'src/2geom/Makefile_insert'?): trying to build r10030 fails when

linking

...

...

inkscape with a lot of 'Undefined symbols' (log attached).

Based on the error messages, I think curve.cpp and bezier.cpp were omitted (these files contain code that was previously in the headers).

Can those two files just be copied from http://bazaar.launchpad.net/~lib2geom- hackers/lib2geom/trunk/files/head:/src/2geom/ or are there other changes needed in inkscape's 2geom files?

Sorry for breaking the build. Of course, it was a bzr (un)usability issue. Again I wonder why we ever switched to bzr... I cannot fix the build or add files because now bzr is broken again here.

I am willing to pay good money to switch our repo back to SVN.

Are you having merge conflicts?

Cheers, Josh

-----Original Message----- From: Krzysztof Kosiński [mailto:tweenk.pl@...400...] Sent: 04 February 2011 00:24 To: ~suv Cc: Inkscape Devel List; Engelen, J.B.C. (Johan) Subject: Re: [Inkscape-devel] Updated 2geom -- what changed?

W dniu 3 lutego 2011 22:11 użytkownik ~suv <suv-sf@...58...> napisał:

...

Can those two files just be copied from <http://bazaar.launchpad.net/~lib2geom-

hackers/lib2geom/trunk/files/head:/src/2geom/>

...

or are there other changes needed in inkscape's 2geom files? ~suv

Build failures should be fixed in 10031. I also fixed a problem with DBus header conflicts that appears if you have sufficiently new giomm.

Thanks for fixing it.

...

Sorry for breaking the build. Of course, it was a bzr (un)usability

issue. Again I wonder why we ever switched to bzr... I cannot fix the build or add files because now bzr is broken again here.

This is not very helpful. What exactly is broken and how does this brokenness manifest? Trying to abandon an unquestionably better tool at the first sight of a problem is not a wise idea. My wild guess is that you somehow copied 2geom's bzr directory into the Inkscape tree. Delete it and things should be back to normal. If they're not, you'll need a fresh checkout.

Wild guesses are not very helpful either.

What happened is that I just copied files into Inkscape's tree, and (tortoise)bzr does not tell me they are unversioned/not-added upon commit. (Tortoisesvn does tell and provides checkboxes to tick which one should be committed and which should not.) So I forgot to add them. Then yesterday I did a bzr update, got the files that Josh added, then tried to bzr add more and... crashes on trying to add files. I did not try with the commandline, as the software should be better than that.

Also here's an useful tip: you can say "bzr add directory" and Bazaar will recursively add all unversioned, non-ignored files it finds in that directory.

Thanks for that tip. Although most often I do not want to add all files.

Again, thanks for fixing the build, Johan

PS. About the unquestionably better tool. I am sure you can find benefits of using Bazaar (note that you are one of the very few that uses branches). But Bazaar is also: - slow - broken (crashing or failing on simple functions) - cumbersome - not providing functionality that I need often, while providing functionality that is rarely used

-----Original Message----- From: Josh Andler [mailto:scislac@...400...] Sent: 04 February 2011 09:06

On Thu, Feb 3, 2011 at 11:55 PM, <J.B.C.Engelen@...1578...>

wrote:

...

• not providing functionality that I need often, while providing

functionality that is rarely used

What are you looking for? As long as I have things like "pull", "push", "add", "commit", "uncommit", "status", "diff", and other basics... I'm pretty good.

(I have become to hate bzr with quite some passion, so my arguments may be biased.) Most of the joy of version control (SVN) is gone for me, since there is no decent UI bzr client with Explorer integration, like TortoiseSVN. Unfortunately TortoiseBZR is *not* close to TortoiseSVN.

From the top of my head here are some things that annoy me:

- that I can no longer see the overlays on file icons that say that the file is changed/unchanged/ignored/unversioned/... (I had to turn off this feature in tortoisebzr, otherwise explorer becomes really slow and unusable; ask any other windows dev) - The commit dialog can be quirky and slow, and does not show earlier commit messages (it can show unversioned files, but does not seem to save the status of the checkbox). - Resolving conflicts is something I do not understand in bzr. (e.g. just now I've been doing all kinds of tricks to get my tree 'correct' again) - No fixed revision numbers?! - I no longer dare to use the bzr update dialog, which also does not provide functionality to keep up-to-date about the source code, like TortoiseSVN does: click button "Show log..." and it only shows the log entries of changes since last update. - when an operation fails halfway, 50% chance of the tree being damaged, and completely new checkout needed, which takes a long time and can again fail halfway... I'm sure there are other devs that can append more to this list. One of the problems of explaining my annoyance with bzr is that if you have not used TortoiseSVN, it is perhaps hard to understand how easy, fun, understandable, and seamless a versioning system can be. For me, a versioning system without a UI is unusable for a big project like Inkscape. (say you want to revert/add/... some files, but not all, but they are spread around the tree a little bit. You'd have to type all those path/filename in the commandline, and of course you are going to forget some files since you have no overview whatsoever. With a UI, simply click some checkboxes)

And to repeat, I really am willing to pay money to go back to SVN.

Ciao, Johan

-----Original Message----- From: Terry Brown [mailto:terry_n_brown@...36...] Sent: 04 February 2011 19:47 To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] bzr rant... Was: Updated 2geom -- what changed?

On Fri, 4 Feb 2011 19:02:20 +0100 <J.B.C.Engelen@...1578...> wrote:

...

(I have become to hate bzr with quite some passion, so my arguments

may

...

be biased.)

:-} that's very honest, anyway - I guess it's only a form of bias if

it

leads you to count things against bzr unfairly.

Personally I use bzr mostly from the command line, but I do sometimes use the QBzr http://wiki.bazaar.canonical.com/QBzr pseudo-gui, invoked for example as

bzr qcommit

These are just some minor factoids in case they're helpful, assuming (?) that a switch from bzr to SVN is unlikely.

Now that we have used bzr for a little over a year, perhaps we can do a poll / evaluation?

• the qcommit interface will show you non-versioned files

This is the commit dialog that I use (right-click in explorer)

also, have you looked at Bzr-explorer, which comes with the standalone windows bzr install?

Yes I have. It is slow and is not a good replacement for file browsing with explorer.

...

• No fixed revision numbers?!

• revision IDs are fixed, they're strings like

  'tbrown@...2561...'

which are of course less appealing than simple numbers, but simple numbers aren't really possible in a distributed peer-to-peer system. Although having said that I thought Ted applied a setting to the lp repo so that subsuming other people's commits into a merged commit of your own is not possible, so lp rev no.s should be fairly fixed.

Is there any way to quickly go to, say, rev ' goejendaagh@...2563...'? (i.e. does it make sense to provide that revision name or not)

so lp rev no.s should be fairly fixed.

How fairly is fairly? I want to be able to refer to unchanged rev numbers after several years.

...

• when an operation fails halfway, 50% chance of the tree being

damaged,

...

and completely new checkout needed, which takes a long time and can again fail halfway...

You can use shared repositories to avoid slow checkouts. Create a directory with bzr init-repo and then branch the lp trunk in there. Afterwards you can delete the trunk branch and branch it again and it should take long at all. I don't use the windows gui bzr tools much, but I know one of them, probably bzr-explorer, asked me about wrapping a branch in a shared repo when I went to branch something the other

day.

I have my tree like that (per Inkscape wiki help). I think you can only quickly (i.e. no internet) branch from an existing branch on the pc? If I delete the trunk branch, what would be the command to quickly branch a new trunk branch? Do I need two trunk branches to do that?

bzr supports multiple distinct workflows, I'm sure things could get confusing if you were mixing parts of different workflows. Personally I only use branch/merge/pull/push, I forget the checkout/update/commit semantics, although I suspect those are closer to SVN style.

I exclusively use checkout/update etc in SVN style workflow. Very few people use branches for Inkscape (check Inkscape's launchpad page) as it usually does not make sense, and you miss out on other people testing what you code. So, the way I see it, we changed to a versioning system that seems oriented to a task that is desired roughly 10 times per year.

Ciao, Johan

Bzr was a big part of me pretty much giving up trying with the main codebase. Last few times I found some spare time to try I just spent an entire evening getting pissed at how difficult something that should be trivial was being made by a bad tool. Slow, unreliable, and fairly incomprehensible.

Sent from my iPhone

On 4 Feb 2011, at 18:02, <J.B.C.Engelen@...1578...> wrote:

...

-----Original Message----- From: Josh Andler [mailto:scislac@...400...] Sent: 04 February 2011 09:06

On Thu, Feb 3, 2011 at 11:55 PM, <J.B.C.Engelen@...1578...>

wrote:

...

...

• not providing functionality that I need often, while providing

functionality that is rarely used

What are you looking for? As long as I have things like "pull", "push", "add", "commit", "uncommit", "status", "diff", and other basics... I'm pretty good.

(I have become to hate bzr with quite some passion, so my arguments may be biased.) Most of the joy of version control (SVN) is gone for me, since there is no decent UI bzr client with Explorer integration, like TortoiseSVN. Unfortunately TortoiseBZR is *not* close to TortoiseSVN.

...

From the top of my head here are some things that annoy me:

• that I can no longer see the overlays on file icons that say that the

file is changed/unchanged/ignored/unversioned/... (I had to turn off this feature in tortoisebzr, otherwise explorer becomes really slow and unusable; ask any other windows dev)

• The commit dialog can be quirky and slow, and does not show earlier

commit messages (it can show unversioned files, but does not seem to save the status of the checkbox).

• Resolving conflicts is something I do not understand in bzr. (e.g.

just now I've been doing all kinds of tricks to get my tree 'correct' again)

• No fixed revision numbers?!
• I no longer dare to use the bzr update dialog, which also does not

provide functionality to keep up-to-date about the source code, like TortoiseSVN does: click button "Show log..." and it only shows the log entries of changes since last update.

• when an operation fails halfway, 50% chance of the tree being damaged,

and completely new checkout needed, which takes a long time and can again fail halfway... I'm sure there are other devs that can append more to this list. One of the problems of explaining my annoyance with bzr is that if you have not used TortoiseSVN, it is perhaps hard to understand how easy, fun, understandable, and seamless a versioning system can be. For me, a versioning system without a UI is unusable for a big project like Inkscape. (say you want to revert/add/... some files, but not all, but they are spread around the tree a little bit. You'd have to type all those path/filename in the commandline, and of course you are going to forget some files since you have no overview whatsoever. With a UI, simply click some checkboxes)

And to repeat, I really am willing to pay money to go back to SVN.

Ciao, Johan

---

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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

checkout that sat there for hours downloading multiple gbs but never produced usable checkout, (thats the main issue with the slow) multiple times when the checkout decided it wasnt a checkout, and refused to accept bzr commands. (ending up with me scratching the entire folder and checking out again - once again, not the fastest process) The tortoise client isnt worth the hardrive it takes to install, which is a huge loss vs how easy svn was to use. It doesnt matter to me that the commands are the same, I never needed to learn any commands with SVN, the client worked.

2011/2/4 Krzysztof Kosiński <tweenk.pl@...400...>:

2011/2/4 John Cliff <john.cliff@...400...>:

...

Bzr was a big part of me pretty much giving up trying with the main codebase. Last few times I found some spare time to try I just spent an entire evening getting pissed at how difficult something that should be trivial was being made by a bad tool. Slow, unreliable, and fairly incomprehensible.

The only slow thing I encountered in Bazaar was the initial checkout and pushing a new branch to LP, everything else is fairly quick - no different from SVN, which also takes some time to do those operations. Committing to a remote branch is far quicker in Bazaar.

As for incomprehensible - replacing "svn" with "bzr" in a corresponding SVN command makes things work 95% of the time. This argument would have some merit if we used Git, which is vastly different and uses a lot of idiosyncratic concepts, but I can't see how it applies to Bazaar. For the user, the only basic thing different between those two is the conflict resolution, which I admit is a little harder in Bazaar.

It would be useful to know what exactly was your problem, otherwise I can't suggest any solution.

Regards, Krzysztof

On Fri, Feb 4, 2011 at 4:54 PM, John Cliff <john.cliff@...400...> wrote:

Bzr was a big part of me pretty much giving up trying with the main codebase. Last few times I found some spare time to try I just spent an entire evening getting pissed at how difficult something that should be trivial was being made by a bad tool. Slow, unreliable, and fairly incomprehensible.

After some experience with other projects using distributed VCSes, I am now of the opinion that in many cases, they cost more than they can bring benefits. Especially if a project has, or intends to attract, inexperienced developers, a distributed VCS becomes a burden: it is much harder to figure out and, critically, much easier to screw up. Yes, you can screw up with SVN as well ("svn resolved" and all that), but it is rare - you need to conflict with someone in exactly the same place of the same file for this to happen; in Bazaar or Mercurial unintended conflicts often become the norm rather than an exception ("oh no I forgot to update before push, again!", "why does it refuse to push?" "where are my changes?" "why won't it merge?" "how to fix the multiple heads I created again?" etc. etc.) This is all learnable, but not before much hair is pulled.

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

SVN with its intuitive simplicity is like Wiki. Much of the success of Wikipedia is due to the simplicity of the Wiki interface for editing. Now they are making it gradually more complex, e.g. with "patrolled" or "flagged" revisions that limit the fundamental edit/view immediacy. They have good reasons for that I'm sure, but it's also clear that if it were like that from the beginning, Wikipedia wouldn't have experienced the explosive growth of its first years.

On Fri, Feb 4, 2011 at 8:47 PM, Alexandre Prokoudine <alexandre.prokoudine@...400...> 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

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@...400...>:

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@...400...> wrote:

...

On Fri, Feb 4, 2011 at 8:47 PM, Alexandre Prokoudine <alexandre.prokoudine@...400...> 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@lists.sourceforge.net 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Hi William,

Windows on git is indeed excellent, thanks to the Git Extensions project:

That is great to hear! Interesting also what you say about TortoiseGit (I would have thought it might come closest to the needs of people missing TortoiseSVN).

Being able to code fearlessly is liberating! Revision control should work with the natural creative flow, not interfere with it. Creativity is messy, though, and nobody wants to submit ugly commits like that. When I'm done coding a new feature, I'll use git's interactive rebase feature to go back and clean up the history, producing a few logical, well-formatted patches to submit upstream:

* Fix the loader bug  * Add the new menu items

It's hard to describe how much better this workflow is. It's something that can only be experienced.

I completely and wholeheartedly agree. My workflow is quite similar to yours, and git's interactive rebase is one of the major things I miss in other version control systems. I know some people say that history should never be changed, but I want and need the freedom to create a right mess in my local repository :), with frequent commits where I can try different things and don't need to worry about whether that's the most sensible way to present them to the rest of the community. Being able to regroup them into nice and logical chunks before pushing, which will make sense to someone browsing the history even in a few months' or years' time is a major advantage and extremely liberating.

Cheers, Max

On Sun, 13 Feb 2011 16:06:57 +0100 Krzysztof Kosiński <tweenk.pl@...400...> wrote:

With regards to Bazaar slowness, it looks like people are only experiencing this because they're trying to use Bazaar in the Git way: by creating a new branch for every minor feature or bugfix.

Using bzr shared repository it takes 12 seconds on my machine to make a branch, cold-cache.

Cheers -Terry

...

...

...

...

"KK" == Krzysztof Kosiński <tweenk.pl@...400...> writes:

KK> 1. No sequential revision numbers. Given commits 09fa34b3 and KK> 23e9f1a0 I can't tell which one is earlier. IIt appears the only KK> reason this was done is to be different from CVS, which Linus hates.

Sequential rev numbers are in generall not physically possible. But to the extent that they can ever work, git supports them via git describe and annotated tags. As an example. one of my kernel trees is now at version v2.6.38-rc4-177-g091994c, where v2.6.38-rc4 is the last annotated tag before that commit, 091994c is the hash of the commit, and 177 is the number of commits between them.

KK> 4. Several important manpages are nearly impossible to understand if KK> you don't already know what the command does.

All projects can benefit from better documentation. The git commiters have shown that they are amiable to patches which improve the quality of their documentation.

KK> 5. Poor support for checkout-update-commit workflow as seen in SVN. KK> Instead of checkout-update-commit, you have clone-pull-commit-push.

That is a non-distributed vs distribute issue. If other DVCSes try to hide that issue under the rug -- and I do not know that any do -- it will only jump out and bite their users in the end.

-JimC

2011/2/4 <J.B.C.Engelen@...1578...>:

(I have become to hate bzr with quite some passion, so my arguments may be biased.)

95% of your complaints are related to TortoiseBZR rather than Bazaar itself.

The GUI situation is not perfect in Bazaar. For now I think it's better to learn to use it from the command line - I've never had problems this way. The CLI is much easier to understand than Git, and in some respects even easier than SVN (for example, no possibility of mixed-revision tree, which never made any sense for me).

You can also check out QBzr; it's not an Explorer extension like Tortoise projects, but it gives you GUI dialogs for most operations. There is a Windows installer here: http://wiki.bazaar.canonical.com/QBzr

• Resolving conflicts is something I do not understand in bzr. (e.g.

just now I've been doing all kinds of tricks to get my tree 'correct' again)

When you have a conflict in file.cpp, 3 files get created: file.cpp.BASE, file.cpp.OTHER, and file.cpp.THIS. file.cpp contains the usual >>>> marks known from SVN. file.cpp.BASE contains the revision of the file at which the versions of file.cpp here and in the merge source diverged. file.cpp.OTHER contains the merge source's version of the file. file.cpp.THIS contains the version of the file from this working tree (merge target). You can fix the conflict by overwriting file.cpp with one of thr above, or editing file.cpp to fix it manually. Once you are done, you need to say "bzr resolve file.cpp" or, equivalently, delete all 3 files listed above (those ending in .BASE, .OTHER and .THIS). The last step is different than in SVN, so it might have been causing you some problems. You can also fix all conflicts at once and then say "bzr resolve --all", which saves you some typing. I think

• I no longer dare to use the bzr update dialog, which also does not

provide functionality to keep up-to-date about the source code, like TortoiseSVN does: click button "Show log..." and it only shows the log entries of changes since last update.

Use "bzr log -l N" where N is the number of latest revisions you want to see.

On POSIX systems you can just say "bzr log -l 100 | less" to scroll through the changelog of 100 most recent revisions. I don't know whether Windows has a pager similar to GNU less.

• when an operation fails halfway, 50% chance of the tree being damaged,

and completely new checkout needed, which takes a long time and can again fail halfway...

I didn't encounter any operations failing halfway, and I never ended up with a broken tree. A few times I had to interrupt a long running command and ended up with a lock on the remote branch, but it was easily solved with "bzr break-lock" (the CLI suggested this command in an error message). I guess it might be TortoiseBZR's fault too.

For me, a versioning system without a UI is unusable for a big project like Inkscape. (say you want to revert/add/... some files, but not all, but they are spread around the tree a little bit. You'd have to type all those path/filename in the commandline, and of course you are going to forget some files since you have no overview whatsoever. With a UI, simply click some checkboxes)

As far as I understand, you can use QBzr to pick files you want to commit / revert / add using a GUI. Since it's not an Explorer extension, it should be much faster than Tortoise.

And to repeat, I really am willing to pay money to go back to SVN.

I am willing to pay 2x more than you to stay with Bazaar, because - for example - I would not be able to maintain the Cairo rendering branch using SVN. It would just take too much time due to SVN slowness. By the way, I'm not dismissing your complaints - I just think that resolving them is going to be much more productive in the long run than going back to a centralized VCS.

Regards, Krzysztof

On 2/4/11, Krzysztof Kosiński wrote:

95% of your complaints are related to TortoiseBZR rather than Bazaar itself.

95% of _my_ complaints are related to the fact that I'm mostly sitting behind slow and expensive connection, while Inkscape's bzr pull *loves* trying to download a dozen of MB of data after just a few commits for no good reason at all, out of blue. This opinion is as biased as one could get, but the truth is that I'm still using a build from July or August *last year* and mostly have no idea what's happening in trunk ever since then. I know I could get a clean checkout once or twice a week, but somehow it isn't fun.

Sorry about bzr hatefest. (Wouldn't trade a DVCS for SVN though.)

Alexandre Prokoudine http://libregraphicsworld.org

On Feb 5, 2011, at 5:39 PM, Martin Owens wrote:

If any of you are _serious_ about trying to improve the ability to use gui tools with bzr and launchpad on gnome. Please help me with GroundControl, I need more developers to go over code (make sure it's not crazy) and add in the features they want to see. Watch the videos on the website linked above, it's really very easy to contribute.

Regards, Martin Owens

Drat! I was looking forward to helping with this, but hit

"! Not Available" "Your OS is not supported yet"

Though it might help some people, we are seeing the biggest need on MS Windows and OS X (including the person who's message had this brought up with).

As a minor point I did try to check things out, but "watch the videos" was not working for me. Between having to share a 'slower' connection (*only* 1.5MB here) and some laggy server response, I couldn't get even the intro one to come up. Videos can be helpful additions, but if they are the sole source of information it makes the graphic designer working out the site on his desktop happy, but causes problems for others.

On Feb 4, 2011, at 10:02 AM, <J.B.C.Engelen@...1578...> wrote:

And to repeat, I really am willing to pay money to go back to SVN

Unfortunatley you seem to be hit by the main drawback with Bazaar - lack of GUI tools. Actually that's a general thing I've seen across most distributed VCS's out there. I think part of this is that the world-view of those writing and using the tools does not intersect some other views of source and source control. Even lack of a good GUI diff is a problem.

I recall that on MS Windows when working with CVS, the best combination I had was using both TortoiseCVS and TkCVS in tandem.

We've gotten to the point where I think I may just have to step up and do something. Extending or fixing TortoiseBZR is not right in my main set of doables right now (a bit hard to do from OS X or Ubuntu), however I think I can get some base tool more like TkCVS/SVN or p4v going.

It seems that merely getting something to check the state of things on a local setup and then assist in following and recommending some of the more efficient Bazaar workflows might be beneficial. Johan, do you think such a tool could help you out?