Re: [Inkscape-devel] Updated 2geom -- what changed?
[ forwarding to the list ]
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?
~suv
-----Original Message----- From: suv@...2204... [mailto:suv@...2204...] On Behalf Of ~suv Sent: 03 February 2011 22:12 To: Krzysztof Kosiński Cc: Inkscape Devel List; Engelen, J.B.C. (Johan) Subject: Re: [Inkscape-devel] Updated 2geom -- what changed?
[ forwarding to the list ]
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.
-Johan
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
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.
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.
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.
Regards, Krzysztof
-----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
On Thu, Feb 3, 2011 at 11:55 PM, <J.B.C.Engelen@...1578...> wrote:
Wild guesses are not very helpful either.
Agreed... which is why questions were asked.
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.
Yeah, once things diverge, they can become messy if you don't have time/patience to shake things out... I won't disagree.
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
Agreed. (to slow, not branches)
- broken (crashing or failing on simple functions)
I think this is tortoisebzr, command line bzr has not had these issues at all for me.
- cumbersome
I find it no less straightforward than svn or git. (more commands than svn, but sensibly)
- 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.
Cheers, Josh
-----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
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.
- the qcommit interface will show you non-versioned files
also, have you looked at Bzr-explorer, which comes with the standalone windows bzr install?
- 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.
- 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.
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.
Cheers -Terry
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
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
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
-----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
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
-----Original Message----- From: Krzysztof Kosiński [mailto:tweenk.pl@...400...] Sent: 04 February 2011 21:57
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
Yes indeed I am complaining about the UI for bzr. I call the whole user experience 'bzr', whether it is the CLI or UI or website. TortoiseBZR is QBzr (plus the icon overlays), by the way. If it is not doable by UI, I refuse to do it (except for 'bzr update'). For two reasons: 1. otherwise it will never get fixed, 2. I don't want to spend time that way. My Inkscape time is extremely limited, and I want to have fun while working on Inkscape. Now I start working a bit on Inkscape again, and... the bzr irritations have started almost immediately :-(
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.
:-) I have maintained an SVN branch for a while (2geomification). That indeed was not so much fun, because there was not a good UI to do it. Once I figured out the svn commands it was OKish. Speed I cannot remember. I suppose indeed for this bzr is easier. But please note that you are one of the really very few devs that have such a big project that it deserves a branch.
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.
Perhaps I should come back after another year, and see if the bzr experience has improved.
Ciao, Johan
-----Original Message----- From: john cliff [mailto:john.cliff@...400...] Sent: 04 February 2011 22:34 To: Krzysztof Kosiński Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] bzr rant... Was: Updated 2geom -- what changed?
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 checkout process has actually been improved on speed by a lot since some new version a while ago. Maybe you can try again and come back? :'(
It doesnt matter to me that the commands are the same, I never needed to learn any commands with SVN, the client worked.
So true.
-Johan
2011/2/4 <J.B.C.Engelen@...1578...>:
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.
The trunk is now set to append only, so once a revision goes into the trunk, it is just as indestructible as it is in SVN. The numbers are guaranteed not to change.
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 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 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.
Alexandre Prokoudine http://libregraphicsworld.org
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
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
And to repeat, I really am willing to pay money to go back to SVN.
I'm going to stick my two giant boots into this conversation. Because I've written bzr gui tools and because I've committed to inkscape using the branch method in the past few months.
Over at http://ground-control.org/ I have attempted to make a tool which very closely follows a clean 'best' workflow when working with bzr. You can watch the videos. I even tested it a few times with the inkscape branch, which does take an age to download.
But bzr has a few neat tricks. One is that you can specify a cache directory when you do your checkout. This sets up a .bzr directory in the specified path where it will cache and link your checkouts together. If you checkout inkscape over here and then checkout a branch for modification over there, it'll only download any of the differences between them for your new branch.
This is enabled by default in GroundControl for obvious reasons. Thanks goes out to a bzr developer who took it upon himself to add the code in himself in a branch in the early days.
I think developers are really hard to deal with when it comes to try and serve them tools. They all know how they work and when you do something revolutionary or different they want to take your eyes out with a spoon for making their lives harder. Bzr and Git are a new and different way to manage code that produces more usable workflows than SVN. You just have to be aware of those workflows before you get angry at the tools.
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
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?
On Sat, 2011-02-05 at 18:40 -0800, Jon Cruz wrote:
Drat! I was looking forward to helping with this, but hit
"! Not Available" "Your OS is not supported yet"
Mac or Windows?
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).
It's python, part of the rationale for getting other devels to take notice is to make sure the code can continue to work when integrated with Finder, Dolphin or Explorer. I'm sure there are probably ways to do it.
Or, by using and modularizing the code more, creating a separate gui tool. Plenty of people have called for a holistic gui tool too.
Neither of those things can happen though with just myself programming, I don't have Mac or Windows machines.
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.
Sorry about that. You could always just right click and save the videos. It's html5, it lets you do awesome. A pdf could be cool, but I have plenty of bugs to work on too. (typical of any project, right?)
Martin,
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
On Sun, Feb 6, 2011 at 4:20 AM, Maximilian Albert <maximilian.albert@...1439...> wrote:
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.
Windows on git is indeed excellent, thanks to the Git Extensions project:
http://code.google.com/p/gitextensions/
I have been using this tool for the past year, and have always been impressed by its speed and stability. More importantly, learning git is pretty easy when you have a graphical view into the repository to show what is happening.
There is another project for Windows, TortoiseGit, but it does not work particularly well. The only advantage of installing TortoiseGit is that it provides colored status icons in the Explorer view, which Git Extensions does not. I had them both installed for a while, but eventually removed TortoiseGit when I realized that I never actually looked at the status icons anymore. The Git Extensions "Commit" window provides a much better answer to the "What has changed?" question than the status icons even did.
In my typical workflow, I keep the Git Extensions "Browse" window open to keep an eye on the project's history (surprisingly useful, and something I never appreciated when using SVN). I also keep a "Commit" window open to see what changes I've made in the working copy. I code like a madman, throwing down commits recklessly:
* fix somethign * oops, forgot to add file * menu stuff * random cleanup
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.
Several people in this thread want to go back to SVN, but that is not a good idea! I used SVN for years, mainly because TortoiseSVN was so incredibly good. The problem with SVN is that you miss out on all the insanely cool things a good DVCS can do. From what I have seen on this thread and experienced first-hand, Bazaar is not a good DVCS; it combines the complexity of a distributed system with all the limits of SVN. Fortunately, git now offers the power of a really good DVCS with the convenience of a really excellent Windows GUI. If you like SVN because of TortoiseSVN, you'll love git because of Git Extensions.
-William
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
-----Original Message----- From: Jon Cruz [mailto:jon@...18...] Sent: 06 February 2011 03:51
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?
I think you should not start creating a new tool. This usually does not work out very well imho in open source land :-) Much more desirable is improve an existing tool.
I guess what we Windows devs are looking for is the shiny polish of TortoiseSVN. TortoiseBZR at the moment has usability gaps and needs speed improvements for every day tasks, compared to TortoiseSVN. It seems there is still active development on TBZR, so... perhaps we should wait and see. I just enabled the icon overlays again for TBZR, it works, and is faster than it used to be. I'll guess I'll start submitting wishlist items to its launchpad page.
Cheers, Johan
2011/2/6 Maximilian Albert <maximilian.albert@...1439...>:
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 don't have any strong opinions on the VCS problem, because I could do everything I wanted with both SVN and Bazaar, and in all probability I could also do it with Git, but with my limited Git knowledge I can point out a few design choices that make very little sense and alienate newbies even further. (Probably some of them could be solved with plugins.)
1. No sequential revision numbers. Given commits 09fa34b3 and 23e9f1a0 I can't tell which one is earlier. IIt appears the only reason this was done is to be different from CVS, which Linus hates. 2. Autocommit of clean merges. (This can be turned off by a parameter, but why the default is almost malicious?) 3. git add and the staging area. This encourages committing something which you did not compile and test. Using bzr shelve / git stash is way better. 4. Several important manpages are nearly impossible to understand if you don't already know what the command does. Example: the summary of "git push" is "Update remote refs along with associated objects". That makes no sense to me if I don't know what "objects" and "refs" mean in Git. By contrast, I was able to learn most of Bazaar via reading manpages and a few Google searches. 5. Poor support for checkout-update-commit workflow as seen in SVN. Instead of checkout-update-commit, you have clone-pull-commit-push.
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. Bazaar will be slow when used this way, because Bazaar creates a working tree for every branch by default, whereas Git has 1 working tree per repository. A simple checkout is enough in this case. You can work Git-style using lightweight checkouts and no working tree repositories, or use the colo plugin that provides some convenience commands. http://doc.bazaar.canonical.com/plugins/en/colo-plugin.html
Regards, Krzysztof
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
2011/2/13 Terry Brown <terry_n_brown@...36...>:
Using bzr shared repository it takes 12 seconds on my machine to make a branch, cold-cache.
Cheers -Terry
This is probably very slow by Git standards, where creating a branch is instantaneous because no files need to be written / changed. 99% of this 12 seconds is probably spent copying the working tree. Making a branch using the colo plugin, or in a no-trees repository, should be almost as fast as in Git.
Some more hints for Git-style branches. http://wiki.bazaar.canonical.com/GitStyleBranches
Regards, Krzysztof
"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
W dniu 17 lutego 2011 23:09 użytkownik James Cloos <cloos@...1016...> napisał:
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.
They might be non-trivial to implement but obviously they are possible, because Bazaar has them. They are branch-local, and there can be some shuffling if you push a diverged branch in place of the original, but they exist and you can force them to monotonically increase in a given branch using the append-only flag, which we use on the trunk.
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.
It's not a DVCS vs. non-DVCS issue, because as with point 1, Bazaar does provide this workflow (and I think we both agree that Bazaar is a DVCS). Internally, Bazaar does the equivalent of commit and push, but the user interface presents this as a commit to a remote repository. Ditto for "update", which is actually a pull and merge.
Regards, Krzysztof
participants (14)
-
unknown＠example.com -
Alexandre Prokoudine -
bulia byak -
James Cloos -
john cliff -
John Cliff
-
Jon Cruz -
Josh Andler -
Krzysztof Kosiński -
Martin Owens -
Maximilian Albert -
Terry Brown -
William Swanson -
~suv