www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Moving to D

reply Adrian Mercieca <amercieca gmail.com> writes:
Hi everyone,

I am currently mulling if I should be adopting D as my (and subsequently 
my company's) language of choice.

We have great experience/investment in C++, so D seems - from what I've 
seen so far - as the logical step; D seems to me to be as C++ done right.
I'm also looking at Go in the process, but Go seems to be more of a 'from 
C' progression, whilst D seems to be the 'from C++' progression.

I am only worried about 2 things though - which I've read on the net:

1. No 64 bit compiler
2. The Phobos vs Tango issue: is this resolved now? This issue represents 
a major stumbling block for me.

Any comments would be greatly appreciated.

Thanks.
Jan 02 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Adrian Mercieca:

Welcome here.

 We have great experience/investment in C++, so D seems - from what I've 
 seen so far - as the logical step;

Maybe.
 D seems to me to be as C++ done right.

"C++ done right" was one of the main purposes for D design :-)
 I'm also looking at Go in the process, but Go seems to be more of a 'from 
 C' progression, whilst D seems to be the 'from C++' progression.

Go and D are quite different. You will probably need a short time to find what do you need more among the two. There is also C# Mono.
 I am only worried about 2 things though - which I've read on the net:

There are other things to be worried about :-)
 1. No 64 bit compiler

It's in development for Linux. It will come, it already compiles some code.
 2. The Phobos vs Tango issue: is this resolved now? This issue represents 
 a major stumbling block for me.

The Phobos vs Tango issue is essentially a D1 issue. If you are interested in D2 then Phobos is going to be good enough. Bye, bearophile
Jan 02 2011
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Adrian Mercieca wrote:
 1. No 64 bit compiler

The 64 bit dmd compiler (for Linux) is nearing alpha stage.
 2. The Phobos vs Tango issue: is this resolved now? This issue represents 
 a major stumbling block for me.

Tango does not exist for D2.
Jan 02 2011
prev sibling next sibling parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Adrian Mercieca wrote:

 Hi everyone,
 
 I am currently mulling if I should be adopting D as my (and subsequently
 my company's) language of choice.
 
 We have great experience/investment in C++, so D seems - from what I've
 seen so far - as the logical step; D seems to me to be as C++ done right.
 I'm also looking at Go in the process, but Go seems to be more of a 'from
 C' progression, whilst D seems to be the 'from C++' progression.
 
 I am only worried about 2 things though - which I've read on the net:
 
 1. No 64 bit compiler
 2. The Phobos vs Tango issue: is this resolved now? This issue represents
 a major stumbling block for me.
 
 Any comments would be greatly appreciated.
 
 Thanks.

64 bit support is the main focus of dmd development at the moment. I take it that you would first evaluate D for a while, possibly 64-bit support will arrive when you are ready and need it. gdc development is also going strong. As for tango vs phobos the situation is now that most of development in the previous version of D (released circa 2007 iirc) is done with Tango. There is also a fine 64-bit compiler for D1, LDC. The feature set of D1 is frozen and significant (some backwards incompatible) changes have been made since. There isn't any sign that Tango will be ported to D2 and phobos is shaping up to be a fine library for D2. Some parts of phobos are still in flux, though other parts are more stable. Perhaps you'll find this thread about experiences with D worth a read: http://thread.gmane.org/gmane.comp.lang.d.general/45993
Jan 02 2011
next sibling parent reply bioinfornatics <bioinfornatics fedoraproject.org> writes:
LDC exist for D2: https://bitbucket.org/prokhin_alexey/ldc2
Same for tango a port to D2 exist, the job is not done: git clone
git://supraverse.net/tango.git
any help are welcome
Jan 02 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/2/11 6:44 AM, Adrian Mercieca wrote:
 On Sun, 02 Jan 2011 11:21:38 +0000, bioinfornatics wrote:

 LDC exist for D2: https://bitbucket.org/prokhin_alexey/ldc2 Same for
 tango a port to D2 exist, the job is not done: git clone
 git://supraverse.net/tango.git any help are welcome

Geez! that was quick! I see that the community is very, very alive. Ok - that clears the issues re 64bit and Phobos vs Tango; Guess Phobos is the way to go with D2. Thanks a lot for your responses - very much appreciated. - Adrian.

I also recommend reading Adam Ruppe's recent posts. His tips on getting great work done in D in spite of its implementation's current imperfections are very valuable. Andrei
Jan 02 2011
prev sibling parent Adrian Mercieca <amercieca gmail.com> writes:
On Sun, 02 Jan 2011 11:21:38 +0000, bioinfornatics wrote:

 LDC exist for D2: https://bitbucket.org/prokhin_alexey/ldc2 Same for
 tango a port to D2 exist, the job is not done: git clone
 git://supraverse.net/tango.git any help are welcome

Geez! that was quick! I see that the community is very, very alive. Ok - that clears the issues re 64bit and Phobos vs Tango; Guess Phobos is the way to go with D2. Thanks a lot for your responses - very much appreciated. - Adrian.
Jan 02 2011
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Adrian Mercieca" <amercieca gmail.com> wrote in message 
news:ifpj8l$lnm$1 digitalmars.com...
 Hi everyone,

 I am currently mulling if I should be adopting D as my (and subsequently
 my company's) language of choice.

 We have great experience/investment in C++, so D seems - from what I've
 seen so far - as the logical step; D seems to me to be as C++ done right.
 I'm also looking at Go in the process, but Go seems to be more of a 'from
 C' progression, whilst D seems to be the 'from C++' progression.

Personally, I love D and can't stand Go (the lack of exceptions, generics, metaprogramming and decent memory-access are deal-breakers for me, and overall it seems like a one-trick pony - it has the interesting goroutines and that's about it). But since this is the D newsgroup you can probably expect we'll be bigger D fans here ;)
 I am only worried about 2 things though - which I've read on the net:

 1. No 64 bit compiler

64-bit code generation is on the way and is Walter's top priority. In the meantime, I would recommend taking a good look at whether it really is necessary for your company's software. Certainly there are many things that benefit greatly from 64-bit, but even as "in-vogue" as 64-bit is, most things don't actually *need* it. And there are still plenty of times when 64-bit won't even make any real difference anyway. But regardless, 64-bit is absolutely on the way and is very high priority. In fact, AIUI, the basic "Hello World" has been working for quite some time now.
 2. The Phobos vs Tango issue: is this resolved now? This issue represents
 a major stumbling block for me.

If you use D2, there is no Tango. Just Phobos. And there are no plans for Tango to move to D2. If you use D1, Tango is really the "de facto" std lib because D1's Phobos is extremely minimal. (D1's Phobos was created way back before there was a real Phobos development team and Walter had to divide his time between language and library, and language was of course the higher priority.) So no, it's really not the issue it's been made out to be.
Jan 02 2011
next sibling parent bioinfornatics <bioinfornatics fedoraproject.org> writes:
they are a D2 port for tango. It is not done. take source here: git clone
git://supraverse.net/tango.git
The job is almost done. everyone can do this job.
Take a D2 compiler build and fix error
Jan 02 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sun, 02 Jan 2011 20:34:40 +0200, bioinfornatics  
<bioinfornatics fedoraproject.org> wrote:

 they are a D2 port for tango. It is not done. take source here: git  
 clone git://supraverse.net/tango.git
 The job is almost done. everyone can do this job.
 Take a D2 compiler build and fix error

How many people are working on this port? How many people will be interested in using it, considering that a direct port won't use many of D2's features (why not just use D1)? Will this port be around in 1 year? 5 years? Will it have the same kind of momentum as the original D1 version, with as many developers working on it, fixing bugs etc.? Will the API always stay in sync with the developments in the original D1 version? What about all the existing documentation, tutorials, even book(s)? Sorry, having more options is a good thing, but I think there is a lot more to a real "Tango for D2" than just someone fixing the code so it compiles and works. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 03 2011
prev sibling next sibling parent Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
 How many people are working on this port? How many people will be interested
 in using it, considering that a direct port won't use many of D2's features
 (why not just use D1)? Will this port be around in 1 year? 5 years? Will it
 have the same kind of momentum as the original D1 version, with as many
 developers working on it, fixing bugs etc.? Will the API always stay in sync
 with the developments in the original D1 version? What about all the
 existing documentation, tutorials, even book(s)?

people seems to have other things to do, partly because most of it works pretty nice already. That said, I think the D2-version of Tango will be a one-time fork. Regarding how many people are working on the D2-fork, I think it's quite few (AFAICT only Marenz). The general consensus in Tango have been to wait on D2 to be "finalized" before investing effort into porting.
 Sorry, having more options is a good thing, but I think there is a lot more
 to a real "Tango for D2" than just someone fixing the code so it compiles
 and works.

port Tango-apps over to D2 with minimal fuzz would is valuable in itself. Anyways, IMHO I think one of the most important advances in D2, is the separation of runtime from system-library, such that Phobos and Tango can co-exist more easily, reducing fragmentation.
Jan 03 2011
prev sibling parent Trass3r <un known.com> writes:
 Agreed, but it doesn't all have to happen at day1. Just being able to
 port Tango-apps over to D2 with minimal fuzz would is valuable in
 itself.

 Anyways, IMHO I think one of the most important advances in D2, is the
 separation of runtime from system-library, such that Phobos and Tango
 can co-exist more easily, reducing fragmentation.

So true.
Jan 03 2011
prev sibling next sibling parent reply Adrian Mercieca <amercieca gmail.com> writes:
Hi,

One other question....

How does D square up, performance-wise, to C and C++ ?
Has anyone got any benchmark figures?

How does D compare in this area?

Also, is D more of a Windows oriented language?
Do the Linux and OSX versions get as much attention as the Windows one?

Thanks.
Adrian.

On Sun, 02 Jan 2011 10:15:49 +0000, Adrian Mercieca wrote:

 Hi everyone,
 
 I am currently mulling if I should be adopting D as my (and subsequently
 my company's) language of choice.
 
 We have great experience/investment in C++, so D seems - from what I've
 seen so far - as the logical step; D seems to me to be as C++ done
 right. I'm also looking at Go in the process, but Go seems to be more of
 a 'from C' progression, whilst D seems to be the 'from C++' progression.
 
 I am only worried about 2 things though - which I've read on the net:
 
 1. No 64 bit compiler
 2. The Phobos vs Tango issue: is this resolved now? This issue
 represents a major stumbling block for me.
 
 Any comments would be greatly appreciated.
 
 Thanks.

Jan 04 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Adrian Mercieca:

 How does D square up, performance-wise, to C and C++ ?
 Has anyone got any benchmark figures?

DMD has an old back-end, it doesn't use SSE (or AVX) registers yet (64 bit version will use 8 or more SSE registers), and sometimes it's slower for integer programs too. I've seen DMD programs slow down if you nest two foreach inside each other. There is a collection of different slow microbenchmarks. But LDC1 is able to run D1 code that looks like C about equally fast as C or sometimes a bit faster. DMD2 uses thread local memory on default that in theory slows code down a bit if you use global data, but I have never seen a benchmark that shows this slowdown clearly (an there is __gshared too, but sometimes it seems a placebo). If you use higher level constructs your program will often go slower. Often one of the most important things for speed is memory management, D encourages to heap allocate a lot (class instances are usually on the heap), and this is very bad for performance, also because the built-in GC doesn't have an Eden generation managed as a stack. So if you want more performance you must program like in Pascal/Ada, stack-allocating a lot, or using memory pools, etc. It's a lot a matter of self-discipline while you program.
 Also, is D more of a Windows oriented language?
 Do the Linux and OSX versions get as much attention as the Windows one?

The Windows version is receiving enough attention, it's not ignored by Walter. But I think for some time the 64 bit version will not be Windows too. Bye, bearophile
Jan 05 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:ig1d3l$kts$1 digitalmars.com...
 Adrian Mercieca:

 How does D square up, performance-wise, to C and C++ ?
 Has anyone got any benchmark figures?

DMD has an old back-end, it doesn't use SSE (or AVX) registers yet (64 bit version will use 8 or more SSE registers), and sometimes it's slower for integer programs too. I've seen DMD programs slow down if you nest two foreach inside each other. There is a collection of different slow microbenchmarks. But LDC1 is able to run D1 code that looks like C about equally fast as C or sometimes a bit faster. DMD2 uses thread local memory on default that in theory slows code down a bit if you use global data, but I have never seen a benchmark that shows this slowdown clearly (an there is __gshared too, but sometimes it seems a placebo). If you use higher level constructs your program will often go slower. Often one of the most important things for speed is memory management, D encourages to heap allocate a lot (class instances are usually on the heap), and this is very bad for performance, also because the built-in GC doesn't have an Eden generation managed as a stack. So if you want more performance you must program like in Pascal/Ada, stack-allocating a lot, or using memory pools, etc. It's a lot a matter of self-discipline while you program.

OTOH, the design of D and Phobos2 strongly encourages fast techniques such as array slicing, pre-computation at compile-time, and appropriate use of things like caching and lazy evaluation. Many of these things probably can be done in C/C++, technically speaking, but D makes them far easier and more accessable, and thus more likely to actually get used. As an example, see how D's built-in array slicing helped Tango's XML lib beat the snot out of other language's fast-XML libs: http://dotnot.org/blog/archives/2008/03/12/why-is-dtango-so- ast-at-parsing-xml/ - and look at the two benchmarks the first paragraph links to.
 Also, is D more of a Windows oriented language?
 Do the Linux and OSX versions get as much attention as the Windows one?


Linux, Windows and OSX are all strongly supported. Sometimes OSX might lag *slightly* in one thing or another, but that's only because there aren't nearly as many people using D on Mac and giving it a good workout. And even at that, it's still only gotten better since Walter got his own Mac box to test on. And Linux is maybe *slightly* ahead of even Windows because, like bearophile said, it'll get 64-bit support first, and also because the Linux DMD uses the standard Linux object-file format while Windows DMD is still using a fairly uncommon object-file format (but that only matters if you want to link object files from different compilers, and if you do want to, I think there are object file converters out there). But yea, overall, all of the big 3 OSes get plenty of attention.
Jan 05 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, January 05, 2011 09:59:08 Andrej Mitrovic wrote:
 On 1/5/11, Nick Sabalausky <a a.a> wrote:
 And Linux is maybe *slightly* ahead of even Windows because, like
 bearophile said, it'll get 64-bit support first..

I wonder if the reason for that is Optlink (iirc it doesn't support 64bit even for DMC, right?).

I believe that it's that and the fact that apparenly 64-bit stuff or Windows is very different from 32-bit stuff, whereas on Linux, for the most part, it's the same. So, it's a much easier port. Of course, Walter would know the specifics on that better than I would. - Jonathan M Davis
Jan 05 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-01-05 18:37, Nick Sabalausky wrote:
 "bearophile"<bearophileHUGS lycos.com>  wrote in message
 news:ig1d3l$kts$1 digitalmars.com...
 Adrian Mercieca:

 How does D square up, performance-wise, to C and C++ ?
 Has anyone got any benchmark figures?

DMD has an old back-end, it doesn't use SSE (or AVX) registers yet (64 bit version will use 8 or more SSE registers), and sometimes it's slower for integer programs too. I've seen DMD programs slow down if you nest two foreach inside each other. There is a collection of different slow microbenchmarks. But LDC1 is able to run D1 code that looks like C about equally fast as C or sometimes a bit faster. DMD2 uses thread local memory on default that in theory slows code down a bit if you use global data, but I have never seen a benchmark that shows this slowdown clearly (an there is __gshared too, but sometimes it seems a placebo). If you use higher level constructs your program will often go slower. Often one of the most important things for speed is memory management, D encourages to heap allocate a lot (class instances are usually on the heap), and this is very bad for performance, also because the built-in GC doesn't have an Eden generation managed as a stack. So if you want more performance you must program like in Pascal/Ada, stack-allocating a lot, or using memory pools, etc. It's a lot a matter of self-discipline while you program.

OTOH, the design of D and Phobos2 strongly encourages fast techniques such as array slicing, pre-computation at compile-time, and appropriate use of things like caching and lazy evaluation. Many of these things probably can be done in C/C++, technically speaking, but D makes them far easier and more accessable, and thus more likely to actually get used. As an example, see how D's built-in array slicing helped Tango's XML lib beat the snot out of other language's fast-XML libs: http://dotnot.org/blog/archives/2008/03/12/why-is-dtango-so- ast-at-parsing-xml/ - and look at the two benchmarks the first paragraph links to.
 Also, is D more of a Windows oriented language?
 Do the Linux and OSX versions get as much attention as the Windows one?


Linux, Windows and OSX are all strongly supported. Sometimes OSX might lag *slightly* in one thing or another, but that's only because there aren't nearly as many people using D on Mac and giving it a good workout. And even at that, it's still only gotten better since Walter got his own Mac box to test on. And Linux is maybe *slightly* ahead of even Windows because, like bearophile said, it'll get 64-bit support first, and also because the Linux DMD uses the standard Linux object-file format while Windows DMD is still using a fairly uncommon object-file format (but that only matters if you want to link object files from different compilers, and if you do want to, I think there are object file converters out there). But yea, overall, all of the big 3 OSes get plenty of attention.

And sometimes Mac OS X is *slightly* ahead of the other OSes, Tango has had support for dynamic libraries on Mac OS X using DMD for quite a while now. For D2 a patch is just sitting there in bugzilla waiting for the last part of it to be commited. I'm really pushing this because people seem to forget this. -- /Jacob Carlborg
Jan 05 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jacob Carlborg:

 And sometimes Mac OS X is *slightly* ahead of the other OSes, Tango has 
 had support for dynamic libraries on Mac OS X using DMD for quite a 
 while now. For D2 a patch is just sitting there in bugzilla waiting for 
 the last part of it to be commited. I'm really pushing this because 
 people seem to forget this.

A quotation from here: http://whatupdave.com/post/1170718843/leaving-net
Also stop using codeplex its not real open source! Real open source isnt
submitting a patch and waiting/hoping that one day it might be accepted and
merged into the main line.<

Bye, bearophile
Jan 05 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:ig2oe8$eki$1 digitalmars.com...
 Jacob Carlborg:

 And sometimes Mac OS X is *slightly* ahead of the other OSes, Tango has
 had support for dynamic libraries on Mac OS X using DMD for quite a
 while now. For D2 a patch is just sitting there in bugzilla waiting for
 the last part of it to be commited. I'm really pushing this because
 people seem to forget this.

A quotation from here: http://whatupdave.com/post/1170718843/leaving-net
Also stop using codeplex its not real open source! Real open source isnt 
submitting a patch and waiting/hoping that one day it might be accepted 
and merged into the main line.<


Automatically accepting all submissions immediately into the main line with no review isn't a good thing either. In that article he's complaining about MS, but MS is notorious for ignoring all non-MS input, period. D's already light-years ahead of that. Since D's purely volunteer effort, and with a lot of things to be done, sometimes things *are* going to tale a while to get in. But there's just no way around that without major risks to quality. And yea Walter could grant main-line DMD commit access to others, but then we'd be left with a situation where no single lead dev understands the whole program inside and out - and when that happens to projects, that's inevitably the point where it starts to go downhill.
Jan 05 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:
 Automatically accepting all submissions immediately into the main line with 
 no review isn't a good thing either. In that article he's complaining about 
 MS, but MS is notorious for ignoring all non-MS input, period. D's already 
 light-years ahead of that. Since D's purely volunteer effort, and with a lot 
 of things to be done, sometimes things *are* going to tale a while to get 
 in. But there's just no way around that without major risks to quality. And 
 yea Walter could grant main-line DMD commit access to others, but then we'd 
 be left with a situation where no single lead dev understands the whole 
 program inside and out - and when that happens to projects, that's 
 inevitably the point where it starts to go downhill.

That's pretty much what I'm afraid of, losing my grip on how the whole thing works if there are multiple dmd committers. On the bright (!) side, Brad Roberts has gotten the test suite in shape so that anyone developing a patch can run it through the full test suite, which is a prerequisite to getting it folded in. In the last release, most of the patches in the changelog were done by people other than myself, although yes, I vet and double check them all before committing them.
Jan 05 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:

Automatically accepting all submissions immediately into the main line with no
review isn't a good thing either.<

I agree with all you have said, I was not suggesting a wild west :-) But maybe there are ways to improve the situation a little, I don't think the current situation is perfect. A better revision control system like Git or Mercury (they are not equal, but both are good enough) will be an improvement. ------------------ Caligo:
 Perhaps using a modern SCM like Git might help?  Everyone could have (and
 should have) commit rights, and they would send pull requests.  You or one
 of the managers would then review the changes and pull and merge with the
 main branch.  It works great; just checkout out Rubinius on Github to see
 what I mean: https://github.com/evanphx/rubinius

I agree. Such systems allow to find a middle point better than the current one between wild freedom and frozen proprietary control. Walter and few others are the only allowed to commit to the main trunk, so Walter has no risk in "losing grip on how the whole thing works", but freedom in submitting patches and creating branches allows people more experimentation, simpler review of patches and trunks, turning D/DMD in a more open source effort... So I suggest Walter to consider all this. Bye, bearophile
Jan 06 2011
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Caligo" <iteronvexor gmail.com> wrote in message 
news:mailman.451.1294306555.4748.digitalmars-d puremagic.com...
 On Thu, Jan 6, 2011 at 12:28 AM, Walter Bright
 <newshound2 digitalmars.com>wrote:

 That's pretty much what I'm afraid of, losing my grip on how the whole
 thing works if there are multiple dmd committers.

 Perhaps using a modern SCM like Git might help?  Everyone could have (and

of the managers would then review the changes and pull and merge with the main branch. It works great; just checkout out Rubinius on Github to see what I mean: https://github.com/evanphx/rubinius

I'm not sure I see how that's any different from everyone having "create and submit a patch" rights, and then having Walter or one of the managers review the changes and merge/patch with the main branch.
Jan 06 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:
 "Caligo" <iteronvexor gmail.com> wrote in message 
 news:mailman.451.1294306555.4748.digitalmars-d puremagic.com...
 On Thu, Jan 6, 2011 at 12:28 AM, Walter Bright
 <newshound2 digitalmars.com>wrote:

 That's pretty much what I'm afraid of, losing my grip on how the whole
 thing works if there are multiple dmd committers.

 Perhaps using a modern SCM like Git might help?  Everyone could have (and

of the managers would then review the changes and pull and merge with the main branch. It works great; just checkout out Rubinius on Github to see what I mean: https://github.com/evanphx/rubinius

I'm not sure I see how that's any different from everyone having "create and submit a patch" rights, and then having Walter or one of the managers review the changes and merge/patch with the main branch.

I don't, either.
Jan 06 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 I don't, either.

Then it's a very good moment for starting to seeing/understanding this and similar things! Bye, bearophile
Jan 06 2011
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
Walter Bright wrote:
 Nick Sabalausky wrote:
 "Caligo" <iteronvexor gmail.com> wrote in message 
 news:mailman.451.1294306555.4748.digitalmars-d puremagic.com...
 On Thu, Jan 6, 2011 at 12:28 AM, Walter Bright
 <newshound2 digitalmars.com>wrote:

 That's pretty much what I'm afraid of, losing my grip on how the whole
 thing works if there are multiple dmd committers.

 Perhaps using a modern SCM like Git might help?  Everyone could have 
 (and

or one of the managers would then review the changes and pull and merge with the main branch. It works great; just checkout out Rubinius on Github to see what I mean: https://github.com/evanphx/rubinius

I'm not sure I see how that's any different from everyone having "create and submit a patch" rights, and then having Walter or one of the managers review the changes and merge/patch with the main branch.

I don't, either.

There's no difference if you're only making one patch, but once you make more, there's a significant difference. I can generally manage to fix about five bugs at once, before they start to interfere with each other. After that, I have to wait for some of the bugs to be integrated into the trunk, or else start discarding changes from my working copy. Occasionally I also use my own DMD local repository, but it doesn't work very well (gets out of sync with the trunk too easily, because SVN isn't really set up for that development model). I think that we should probably move to Mercurial eventually. I think there's potential for two benefits: (1) quicker for you to merge changes in; (2) increased collaboration between patchers. But due to the pain in changing the developement model, I don't think it's a change we should make in the near term.
Jan 06 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/6/11 9:18 AM, Don wrote:
 Walter Bright wrote:
 Nick Sabalausky wrote:
 "Caligo" <iteronvexor gmail.com> wrote in message
 news:mailman.451.1294306555.4748.digitalmars-d puremagic.com...
 On Thu, Jan 6, 2011 at 12:28 AM, Walter Bright
 <newshound2 digitalmars.com>wrote:

 That's pretty much what I'm afraid of, losing my grip on how the whole
 thing works if there are multiple dmd committers.

 Perhaps using a modern SCM like Git might help? Everyone could have
 (and

or one of the managers would then review the changes and pull and merge with the main branch. It works great; just checkout out Rubinius on Github to see what I mean: https://github.com/evanphx/rubinius

I'm not sure I see how that's any different from everyone having "create and submit a patch" rights, and then having Walter or one of the managers review the changes and merge/patch with the main branch.

I don't, either.

There's no difference if you're only making one patch, but once you make more, there's a significant difference. I can generally manage to fix about five bugs at once, before they start to interfere with each other. After that, I have to wait for some of the bugs to be integrated into the trunk, or else start discarding changes from my working copy. Occasionally I also use my own DMD local repository, but it doesn't work very well (gets out of sync with the trunk too easily, because SVN isn't really set up for that development model). I think that we should probably move to Mercurial eventually. I think there's potential for two benefits: (1) quicker for you to merge changes in; (2) increased collaboration between patchers. But due to the pain in changing the developement model, I don't think it's a change we should make in the near term.

What are the advantages of Mercurial over git? (git does allow multiple branches.) Andrei
Jan 06 2011
next sibling parent bioinfornatics <bioinfornatics fedoraproject.org> writes:
i have used svn, cvs a little, mercurial and git and i prefer git for me is
better way
Very powerfull for managing branch and do merge. Chery pick is too very
powerfull.
And yes git allow multi branch
Jan 06 2011
prev sibling next sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Andrei Alexandrescu wrote:
 What are the advantages of Mercurial over git? (git does allow multiple=

 branches.)
=20

Here's a comparison. Although I am partial to Mercurial, I have tried to be fair. Some of the points are in favor of Mercurial, some in favor of Git, and some are simply differences I noted (six of one, half a dozen of the other): http://www.digitalmars.com/pnews/read.php?server=3Dnews.digitalmars.com&g= roup=3Ddigitalmars.D&artnum=3D91657 An extra point I did not raise at the time: Git is deliberately engineered to be as different from CVS/SVN as possible (quoting Wikipedia: "Take CVS as an example of what /not/ to do; if in doubt, make the exact opposite decision"). IMO this makes it a poor choice when migrating from SVN. Mercurial (or Bazaar) would be much more comfortable. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jan 06 2011
next sibling parent David Nadlinger <see klickverbot.at> writes:
On 1/6/11 8:19 PM, "Jérôme M. Berger" wrote:
 	Here's a comparison. Although I am partial to Mercurial, I have
 tried to be fair.

Jérôme, I'm usually not the one arguing ad hominem, but are you sure that you really tried to be fair? If you want to make subjective statements about Mercurial, that you personally like it better because of this and that reason, that's fine, but please don't try to make it look like an objective comparison. A fair part of the arguments you made in the linked post are objectively wrong, which is understandable if you're mainly a Mercurial user – but please don't make it look like you had done more in-depth research regarding both to other people… For example, you dwelt on being able to »hg pull help« being an advantage over Git – where the equivalent command reads »git pull --help«. Are you serious?! By the way, at least for Mercurial 1.6, you need to pass »--help« as a »proper« argument using two dashes as well, your command does not work (anymore).
 	An extra point I did not raise at the time: Git is deliberately
 engineered to be as different from CVS/SVN as possible (quoting
 Wikipedia: "Take CVS as an example of what /not/ to do; if in doubt,
 make the exact opposite decision").

You missed the »… quote Torvalds, speaking somewhat tongue-in-cheek« part – in the talk the quote is from, Linus Torvalds was making the point that centralized SCMs just can't keep up with distributed concepts, and as you probably know, he really likes to polarize. In the same talk, he also mentioned Mercurial being very similar to Git – does that make it an unfavorable switch as well in your eyes? I hope not… David
Jan 06 2011
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 06/01/2011 19:19, "Jérôme M. Berger" wrote:
 Andrei Alexandrescu wrote:
 What are the advantages of Mercurial over git? (git does allow multiple
 branches.)


I've also been mulling over whether to try out and switch away from Subversion to a DVCS, but never went ahead cause I've also been undecided about Git vs. Mercurial. So this whole discussion here in the NG has been helpful, even though I rarely use branches, if at all. However, there is an important issue for me that has not been mentioned ever, I wonder if other people also find it relevant. It annoys me a lot in Subversion, and basically it's the aspect where if you delete, rename, or copy a folder under version control in a SVN working copy, without using the SVN commands, there is a high likelihood your working copy will break! It's so annoying, especially since sometimes no amount of svn revert, cleanup, unlock, override and update, etc. will fix it. I just had one recently where I had to delete and re-checkout the whole project because it was that broken. Other situations also seem to cause this, even when using SVN tooling (like partially updating from a commit that delete or moves directories, or something like that) It's just so brittle. I think it may be a consequence of the design aspect of SVN where each subfolder of a working copy is a working copy as well (and each subfolder of repository is a repository as well) Anyways, I hope Mercurial and Git are better at this, I'm definitely going to try them out with regards to this. -- Bruno Medeiros - Software Engineer
Jan 28 2011
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-01-28 11:29:49 -0500, Bruno Medeiros 
<brunodomedeiros+spam com.gmail> said:

 I've also been mulling over whether to try out and switch away from 
 Subversion to a DVCS, but never went ahead cause I've also been 
 undecided about Git vs. Mercurial. So this whole discussion here in the 
 NG has been helpful, even though I rarely use branches, if at all.
 
 However, there is an important issue for me that has not been mentioned 
 ever, I wonder if other people also find it relevant. It annoys me a 
 lot in Subversion, and basically it's the aspect where if you delete, 
 rename, or copy a folder under version control in a SVN working copy, 
 without using the SVN commands, there is a high likelihood your working 
 copy will break! It's so annoying, especially since sometimes no amount 
 of svn revert, cleanup, unlock, override and update, etc. will fix it. 
 I just had one recently where I had to delete and re-checkout the whole 
 project because it was that broken.
 Other situations also seem to cause this, even when using SVN tooling 
 (like partially updating from a commit that delete or moves 
 directories, or something like that) It's just so brittle.
 I think it may be a consequence of the design aspect of SVN where each 
 subfolder of a working copy is a working copy as well (and each 
 subfolder of repository is a repository as well)
 
 Anyways, I hope Mercurial and Git are better at this, I'm definitely 
 going to try them out with regards to this.

Git doesn't care how you move your files around. It track files by their content. If you rename a file and most of the content stays the same, git will see it as a rename. If most of the file has changed, it'll see it as a new file (with the old one deleted). There is 'git mv', but it's basically just a shortcut for moving the file, doing 'git rm' on the old path and 'git add' on the new path. I don't know about Mercurial. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 28 2011
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Michel Fortin wrote:
 On 2011-01-28 11:29:49 -0500, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> said:
=20
 I've also been mulling over whether to try out and switch away from
 Subversion to a DVCS, but never went ahead cause I've also been
 undecided about Git vs. Mercurial. So this whole discussion here in
 the NG has been helpful, even though I rarely use branches, if at all.=


 However, there is an important issue for me that has not been
 mentioned ever, I wonder if other people also find it relevant. It
 annoys me a lot in Subversion, and basically it's the aspect where if
 you delete, rename, or copy a folder under version control in a SVN
 working copy, without using the SVN commands, there is a high
 likelihood your working copy will break! It's so annoying, especially
 since sometimes no amount of svn revert, cleanup, unlock, override and=


 update, etc. will fix it. I just had one recently where I had to
 delete and re-checkout the whole project because it was that broken.
 Other situations also seem to cause this, even when using SVN tooling
 (like partially updating from a commit that delete or moves
 directories, or something like that) It's just so brittle.
 I think it may be a consequence of the design aspect of SVN where each=


 subfolder of a working copy is a working copy as well (and each
 subfolder of repository is a repository as well)

 Anyways, I hope Mercurial and Git are better at this, I'm definitely
 going to try them out with regards to this.

Git doesn't care how you move your files around. It track files by thei=

 content. If you rename a file and most of the content stays the same,
 git will see it as a rename. If most of the file has changed, it'll see=

 it as a new file (with the old one deleted). There is 'git mv', but it'=

 basically just a shortcut for moving the file, doing 'git rm' on the ol=

 path and 'git add' on the new path.
=20
 I don't know about Mercurial.
=20

pass the -A option to "hg cp" or "hg mv"). It also has the "addremove" command which will automatically remove any missing files and add any unknown non-ignored files. Addremove can detect renamed files if they are similar enough to the old file (the similarity level is configurable) but it will not detect copies. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jan 29 2011
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 29/01/2011 10:02, "Jérôme M. Berger" wrote:
 Michel Fortin wrote:
 On 2011-01-28 11:29:49 -0500, Bruno Medeiros
 <brunodomedeiros+spam com.gmail>  said:

 I've also been mulling over whether to try out and switch away from
 Subversion to a DVCS, but never went ahead cause I've also been
 undecided about Git vs. Mercurial. So this whole discussion here in
 the NG has been helpful, even though I rarely use branches, if at all.

 However, there is an important issue for me that has not been
 mentioned ever, I wonder if other people also find it relevant. It
 annoys me a lot in Subversion, and basically it's the aspect where if
 you delete, rename, or copy a folder under version control in a SVN
 working copy, without using the SVN commands, there is a high
 likelihood your working copy will break! It's so annoying, especially
 since sometimes no amount of svn revert, cleanup, unlock, override and
 update, etc. will fix it. I just had one recently where I had to
 delete and re-checkout the whole project because it was that broken.
 Other situations also seem to cause this, even when using SVN tooling
 (like partially updating from a commit that delete or moves
 directories, or something like that) It's just so brittle.
 I think it may be a consequence of the design aspect of SVN where each
 subfolder of a working copy is a working copy as well (and each
 subfolder of repository is a repository as well)

 Anyways, I hope Mercurial and Git are better at this, I'm definitely
 going to try them out with regards to this.

Git doesn't care how you move your files around. It track files by their content. If you rename a file and most of the content stays the same, git will see it as a rename. If most of the file has changed, it'll see it as a new file (with the old one deleted). There is 'git mv', but it's basically just a shortcut for moving the file, doing 'git rm' on the old path and 'git add' on the new path. I don't know about Mercurial.

pass the -A option to "hg cp" or "hg mv"). It also has the "addremove" command which will automatically remove any missing files and add any unknown non-ignored files. Addremove can detect renamed files if they are similar enough to the old file (the similarity level is configurable) but it will not detect copies. Jerome

Indeed, that's want I found out now that I tried Mercurial. So that's really nice (especially the "addremove" command), it's actually motivation enough for me to switch to Mercurial or Git, as it's a major annoyance in SVN. I've learned a few more things recently: there's a minor issue with Git and Mercurial in that they both are not able to record empty directories. A very minor annoyance (it's workaround-able), but still conceptually lame, I mean, directories are resources too! It's curious that the wiki pages for both Git and Mercurial on this issue are exactly the same, word by word most of them: http://mercurial.selenic.com/wiki/MarkEmptyDirs https://git.wiki.kernel.org/index.php/MarkEmptyDirs (I guess it's because they were written by the same guy) A more serious issue that I learned (or rather forgotten about before and remembered now) is the whole DVCSes keep the whole repository history locally aspect, which has important ramifications. If the repository is big, although disk space may not be much of an issue, it's a bit annoying when copying the repository locally(*), or cloning it from the internet and thus having to download large amounts of data. For example in the DDT Eclipse IDE I keep the project dependencies (https://svn.codespot.com/a/eclipselabs.org/ddt/trunk/org.dsourc .ddt-build/target/) on source control, which is 141Mb total on a single revision, and they might change ever semester or so... I'm still not sure what to do about this. I may split this part of the project into a separate Mercurial repository, although I do lose some semantic information because of this: a direct association between each revision in the source code projects, and the corresponding revision in the dependencies project. Conceptually I would want this to be a single repository. (*) Yeah, I know Mercurial and Git may use hardlinks to speed up the cloning process, even on Windows, but that solution is not suitable to me, as I my workflow is usually to copy entire Eclipse workspaces when I want to "branch" on some task. Doesn't happen that often though. -- Bruno Medeiros - Software Engineer
Feb 01 2011
next sibling parent David Nadlinger <see klickverbot.at> writes:
On 2/1/11 2:44 PM, Bruno Medeiros wrote:
 […] a direct association between each
 revision in the source code projects, and the corresponding revision in
 the dependencies project. […]

With Git, you could use submodules for that task – I don't know if something similar exists for Mercurial. David
Feb 01 2011
prev sibling next sibling parent foobar <foo bar.com> writes:
Bruno Medeiros Wrote:

 On 29/01/2011 10:02, "Jérôme M. Berger" wrote:
 Michel Fortin wrote:
 On 2011-01-28 11:29:49 -0500, Bruno Medeiros
 <brunodomedeiros+spam com.gmail>  said:

 I've also been mulling over whether to try out and switch away from
 Subversion to a DVCS, but never went ahead cause I've also been
 undecided about Git vs. Mercurial. So this whole discussion here in
 the NG has been helpful, even though I rarely use branches, if at all.

 However, there is an important issue for me that has not been
 mentioned ever, I wonder if other people also find it relevant. It
 annoys me a lot in Subversion, and basically it's the aspect where if
 you delete, rename, or copy a folder under version control in a SVN
 working copy, without using the SVN commands, there is a high
 likelihood your working copy will break! It's so annoying, especially
 since sometimes no amount of svn revert, cleanup, unlock, override and
 update, etc. will fix it. I just had one recently where I had to
 delete and re-checkout the whole project because it was that broken.
 Other situations also seem to cause this, even when using SVN tooling
 (like partially updating from a commit that delete or moves
 directories, or something like that) It's just so brittle.
 I think it may be a consequence of the design aspect of SVN where each
 subfolder of a working copy is a working copy as well (and each
 subfolder of repository is a repository as well)

 Anyways, I hope Mercurial and Git are better at this, I'm definitely
 going to try them out with regards to this.

Git doesn't care how you move your files around. It track files by their content. If you rename a file and most of the content stays the same, git will see it as a rename. If most of the file has changed, it'll see it as a new file (with the old one deleted). There is 'git mv', but it's basically just a shortcut for moving the file, doing 'git rm' on the old path and 'git add' on the new path. I don't know about Mercurial.

pass the -A option to "hg cp" or "hg mv"). It also has the "addremove" command which will automatically remove any missing files and add any unknown non-ignored files. Addremove can detect renamed files if they are similar enough to the old file (the similarity level is configurable) but it will not detect copies. Jerome

Indeed, that's want I found out now that I tried Mercurial. So that's really nice (especially the "addremove" command), it's actually motivation enough for me to switch to Mercurial or Git, as it's a major annoyance in SVN. I've learned a few more things recently: there's a minor issue with Git and Mercurial in that they both are not able to record empty directories. A very minor annoyance (it's workaround-able), but still conceptually lame, I mean, directories are resources too! It's curious that the wiki pages for both Git and Mercurial on this issue are exactly the same, word by word most of them: http://mercurial.selenic.com/wiki/MarkEmptyDirs https://git.wiki.kernel.org/index.php/MarkEmptyDirs (I guess it's because they were written by the same guy) A more serious issue that I learned (or rather forgotten about before and remembered now) is the whole DVCSes keep the whole repository history locally aspect, which has important ramifications. If the repository is big, although disk space may not be much of an issue, it's a bit annoying when copying the repository locally(*), or cloning it from the internet and thus having to download large amounts of data. For example in the DDT Eclipse IDE I keep the project dependencies (https://svn.codespot.com/a/eclipselabs.org/ddt/trunk/org.dsourc .ddt-build/target/) on source control, which is 141Mb total on a single revision, and they might change ever semester or so... I'm still not sure what to do about this. I may split this part of the project into a separate Mercurial repository, although I do lose some semantic information because of this: a direct association between each revision in the source code projects, and the corresponding revision in the dependencies project. Conceptually I would want this to be a single repository. (*) Yeah, I know Mercurial and Git may use hardlinks to speed up the cloning process, even on Windows, but that solution is not suitable to me, as I my workflow is usually to copy entire Eclipse workspaces when I want to "branch" on some task. Doesn't happen that often though. -- Bruno Medeiros - Software Engineer

You raised a valid concern regarding the local copy issue and it has already been taken care of in DVCSes: 1. git stores all the actual data in "blobs" which are compressed whereas svn stores everything in plain-text (including all the history!) 2. git stores and transfers deltas and not full files unlike svn 3. it's possible to wrap a bunch of commits into a "bundle" - a single compressed binary file. This file can be than downloaded and than you can git fetch from it. In general Git (and I assume mercurial as well) both needs way less space than comparable SVN repositories and is much faster in fetching from upstream compared to svn update. Try cloning your svn repository with git-svn and compare repository sizes..
Feb 01 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Bruno Medeiros wrote:
 A more serious issue that I learned (or rather forgotten about before 
 and remembered now) is the whole DVCSes keep the whole repository 
 history locally aspect, which has important ramifications. If the 
 repository is big, although disk space may not be much of an issue,

I still find myself worrying about disk usage, despite being able to get a 2T drive these days for under a hundred bucks. Old patterns of thought die hard.
Feb 01 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Brad Roberts wrote:
 Ie, essentially negligable.

Yeah, and I caught myself worrying about the disk usage from having two clones of the git repository (one for D1, the other for D2).
Feb 01 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrej Mitrovic wrote:
 I don't know what to say..

Git is a Linux program and will never work right on Windows. The problems you're experiencing are classic ones I find whenever I attempt to use a Linux program that has been "ported" to Windows.
Feb 01 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Andrej Mitrovic wrote:
 Is this why you've made your own version of make and microemacs for
 Windows? I honestly can't blame you. :)

Microemacs floated around the intarnets for free back in the 80's, and I liked it because it was very small, fast, and customizable. Having an editor that fit in 50k was just the ticket for a floppy based system. Most code editors of the day were many times larger, took forever to load, etc. I wrote my own make because I needed one to sell and so couldn't use someone else's.
Feb 01 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Andrej Mitrovic wrote:
 I've noticed you have "Version Control with Git" listed in your list
 of books. Did you just buy that recently, or were you secretly
 planning to switch to Git at the instant someone mentioned it? :p

I listed it recently.
Feb 01 2011
prev sibling next sibling parent David Nadlinger <see klickverbot.at> writes:
On 2/2/11 3:17 AM, Andrej Mitrovic wrote:
 Bleh. I tried to use Git to update some of the doc files, but getting
 the thing to work will be a miracle.

 git can't find the public keys unless I use msysgit. Great. How
 exactly do I cd to D:\ ?

If you are new to Git or SSH, the folks at GitHub have put up a tutorial explaining how to generate and set up a pair of SSH keys: http://help.github.com/msysgit-key-setup/. There is also a page describing solutions to some SSH setup problems: http://help.github.com/troubleshooting-ssh/. If you already have a private/public key and want to use it with Git, either copy them to Git's .ssh/ directory or edit the .ssh/config of the SSH instance used by Git accordingly. If you need to refer to »D:\somefile« inside the MSYS shell, use »/d/somefile«. I don't quite get what you mean with »git can't find the public keys unless I use msysgit«. Obviously, you need to modify the configuration of the SSH program Git uses, but other than that, you don't need to use the MSYS shell for setting up stuff – you can just use Windows Explorer and your favorite text editor for that as well. David
Feb 02 2011
prev sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Andrej Mitrovic wrote:
 Bleh. I tried to use Git to update some of the doc files, but getting
 the thing to work will be a miracle.
=20
 git can't find the public keys unless I use msysgit. Great. How
 exactly do I cd to D:\ ?
=20
 So I try git-gui. Seems to work fine, I clone the forked repo and make
 a few changes. I try to commit, it says I have to update first. So I
 do that. *Error: crash crash crash*. I try to close the thing, it just
 keeps crashing. CTRL+ALT+DEL time..
=20
 Okay, I try another GUI package, GitExtensions. I make new
 public/private keys and add it to github, I'm about to clone but then
 I get this "fatal: The remote end hung up unexpectedly".
=20
 I don't know what to say..

Why do you think I keep arguing against Git every chance I get? Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Feb 02 2011
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 01/02/2011 23:07, Walter Bright wrote:
 Bruno Medeiros wrote:
 A more serious issue that I learned (or rather forgotten about before
 and remembered now) is the whole DVCSes keep the whole repository
 history locally aspect, which has important ramifications. If the
 repository is big, although disk space may not be much of an issue,

I still find myself worrying about disk usage, despite being able to get a 2T drive these days for under a hundred bucks. Old patterns of thought die hard.

Well, like I said, my concern about size is not so much disk space, but the time to make local copies of the repository, or cloning it from the internet (and the associated transfer times), both of which are not neglectable yet. My project at work could easily have gone to 1Gb of repo size if in the last year or so it has been stored on a DVCS! :S I hope this gets addressed at some point. But I fear that the main developers of both Git and Mercurial may be too "biased" to experience projects which are typically somewhat small in size, in terms of bytes (projects that consist almost entirely of source code). For example, in UI applications it would be common to store binary data (images, sounds, etc.) in the source control. The other case is what I mentioned before, wanting to store dependencies together with the project (in my case including the javadoc and source code of the dependencies - and there's very good reasons to want to do that). In this analysis: http://code.google.com/p/support/wiki/DVCSAnalysis they said that Git has some functionality to address this issue: "Client Storage Management. Both Mercurial and Git allow users to selectively pull branches from other repositories. This provides an upfront mechanism for narrowing the amount of history stored locally. In addition, Git allows previously pulled branches to be discarded. Git also allows old revision data to be pruned from the local repository (while still keeping recent revision data on those branches). With Mercurial, if a branch is in the local repository, then all of its revisions (back to the very initial commit) must also be present, and there is no way to prune branches other than by creating a new repository and selectively pulling branches into it. There has been some work addressing this in Mercurial, but nothing official yet." However I couldn't find more info about this, and other articles and comments about Git seem to omit or contradict this... :S Can Git really have an usable but incomplete local clone? -- Bruno Medeiros - Software Engineer
Feb 04 2011
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-02-04 11:12:12 -0500, Bruno Medeiros 
<brunodomedeiros+spam com.gmail> said:

 Can Git really have an usable but incomplete local clone?

Yes, it's called a shallow clone. See the --depth switch of git clone: <http://www.kernel.org/pub/software/scm/git/docs/git-clone.html> -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 04 2011
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 04/02/2011 20:11, Michel Fortin wrote:
 On 2011-02-04 11:12:12 -0500, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> said:

 Can Git really have an usable but incomplete local clone?

Yes, it's called a shallow clone. See the --depth switch of git clone: <http://www.kernel.org/pub/software/scm/git/docs/git-clone.html>

I was about to say "Cool!", but then I checked the doc on that link and it says: "A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches. " So it's actually not good for what I meant, since it is barely usable (you cannot push from it). :( -- Bruno Medeiros - Software Engineer
Feb 09 2011
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-02-09 07:49:31 -0500, Bruno Medeiros 
<brunodomedeiros+spam com.gmail> said:

 On 04/02/2011 20:11, Michel Fortin wrote:
 On 2011-02-04 11:12:12 -0500, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> said:
 
 Can Git really have an usable but incomplete local clone?

Yes, it's called a shallow clone. See the --depth switch of git clone: <http://www.kernel.org/pub/software/scm/git/docs/git-clone.html>

I was about to say "Cool!", but then I checked the doc on that link and it says: "A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches. " So it's actually not good for what I meant, since it is barely usable (you cannot push from it). :(

Actually, pushing from a shallow repository can work, but if your history is not deep enough it will be a problem when git tries determine the common ancestor. Be sure to have enough depth so that your history contains the common ancestor of all the branches you might want to merge, and also make sure the remote repository won't rewrite history beyond that point and you should be safe. At least, that's what I understand from: <http://git.661346.n2.nabble.com/pushing-from-a-shallow-repo-allowed-td2332252.html> -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 09 2011
next sibling parent "nedbrek" <nedbrek yahoo.com> writes:
Hello all,

"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:iiu8dm$10te$1 digitalmars.com...
 On 2011-02-09 07:49:31 -0500, Bruno Medeiros 
 <brunodomedeiros+spam com.gmail> said:
 On 04/02/2011 20:11, Michel Fortin wrote:
 On 2011-02-04 11:12:12 -0500, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> said:

 Can Git really have an usable but incomplete local clone?

Yes, it's called a shallow clone. See the --depth switch of git clone: <http://www.kernel.org/pub/software/scm/git/docs/git-clone.html>

I was about to say "Cool!", but then I checked the doc on that link and it says: "A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches. " So it's actually not good for what I meant, since it is barely usable (you cannot push from it). :(

Actually, pushing from a shallow repository can work, but if your history is not deep enough it will be a problem when git tries determine the common ancestor. Be sure to have enough depth so that your history contains the common ancestor of all the branches you might want to merge, and also make sure the remote repository won't rewrite history beyond that point and you should be safe. At least, that's what

The other way to collaborate is to email someone a diff. Git has a lot of support for extracting diffs from emails and applying the patches. HTH, Ned
Feb 10 2011
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 09/02/2011 14:27, Michel Fortin wrote:
 On 2011-02-09 07:49:31 -0500, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> said:

 On 04/02/2011 20:11, Michel Fortin wrote:
 On 2011-02-04 11:12:12 -0500, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> said:

 Can Git really have an usable but incomplete local clone?

Yes, it's called a shallow clone. See the --depth switch of git clone: <http://www.kernel.org/pub/software/scm/git/docs/git-clone.html>

I was about to say "Cool!", but then I checked the doc on that link and it says: "A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches. " So it's actually not good for what I meant, since it is barely usable (you cannot push from it). :(

Actually, pushing from a shallow repository can work, but if your history is not deep enough it will be a problem when git tries determine the common ancestor. Be sure to have enough depth so that your history contains the common ancestor of all the branches you might want to merge, and also make sure the remote repository won't rewrite history beyond that point and you should be safe. At least, that's what I understand from: <http://git.661346.n2.nabble.com/pushing-from-a-shallow-repo-allowed-td2332252.html>

Interesting. But it still feels very much like a second-class functionality, not something they really have in mind to support well, at least not yet. Ideally, if one wants to do push but the ancestor history is incomplete, the VCS would download from the central repository whatever revision/changeset information was missing. Before someone says, oh but that defeats some of the purposes of a distributed VCS, like being able to work offline. I know, and I personally don't care that much, in fact I find this "benefit" of DVCS has been overvalued way out of proportion. Does anyone do any serious coding while being offline for an extended period of time? Some people mentioned coding on the move, with laptops, but seriously, even if I am connected to the Internet I cannot code with my laptop only, I need it connected to a monitor, as well as a mouse, (and preferably a keyboard as well). -- Bruno Medeiros - Software Engineer
Feb 11 2011
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-02-11 08:05:27 -0500, Bruno Medeiros 
<brunodomedeiros+spam com.gmail> said:

 On 09/02/2011 14:27, Michel Fortin wrote:
 On 2011-02-09 07:49:31 -0500, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> said:
 
 I was about to say "Cool!", but then I checked the doc on that link
 and it says:
 "A shallow repository has a number of limitations (you cannot clone or
 fetch from it, nor push from nor into it), but is adequate if you are
 only interested in the recent history of a large project with a long
 history, and would want to send in fixes as patches. "
 So it's actually not good for what I meant, since it is barely usable
 (you cannot push from it). :(

Actually, pushing from a shallow repository can work, but if your history is not deep enough it will be a problem when git tries determine the common ancestor. Be sure to have enough depth so that your history contains the common ancestor of all the branches you might want to merge, and also make sure the remote repository won't rewrite history beyond that point and you should be safe. At least, that's what I understand from: <http://git.661346.n2.nabble.com/pushing-from-a-shallow-repo-allowed-td2332252.html>


Interesting.
 

something they really have in mind to support well, at least not yet. Ideally, if one wants to do push but the ancestor history is incomplete, the VCS would download from the central repository whatever revision/changeset information was missing.

Actually, there's no "central" repository in Git. But I agree with your idea in general: one of the remotes could be designated as being a source to look for when encountering a missing object, probably the one from which you shallowly cloned from. All we need is someone to implement that. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 11 2011
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 11/02/2011 18:31, Michel Fortin wrote:
 Ideally, if one wants to do push but the ancestor history is
 incomplete, the VCS would download from the central repository
 whatever revision/changeset information was missing.

Actually, there's no "central" repository in Git.

That stuff about DVCS not having a central repository is another thing that is being said a lot, but is only true in a very shallow (and non-useful) way. Yes, in DVCS there are no more "working copies" as in Subversion, now everyone's working copy is a full fledged repository/clone that in technical terms is peer of any other repository. However, from an organizational point of view in a project, there is always going to be a "central" repository. The one that actually represents the product/application/library, where the builds and releases are made from. (Of course, there could be more than one central repository if there are multiple kinds of releases like stable/experimental, or forks of the the product, etc.) Maybe the DVCS world likes the term public/shared repository better, but that doesn't make much difference. -- Bruno Medeiros - Software Engineer
Feb 16 2011
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 16/02/2011 17:54, Ulrik Mikaelsson wrote:
 2011/2/16 Russel Winder<russel russel.org.uk>:
 Definitely the case.  There can only be one repository that represents
 the official state of a given project.  That isn't really the issue in
 the move from CVCS systems to DVCS systems.

Many projects are centered around the concept of a centralized project, a "core"-team, and all-around central organisation and planning. Some projects however, I guess the Linux kernel is a prime example, have been quite de-centralized even in their nature for a long time. In the case of KDE, for a centralized example, there is a definite "project version", which is the version currently blessed by the central project team. There is a centralized project planning, including meetings, setting out goals for the coming development. In the case of Linux, it's FAR less obvious. Sure, most people see master torvalds/linux-2.6.git as THE Linux-version. However, there are many other trees interesting to track as well, such as the various distribution-trees which might incorporate many drivers not in mainline, especially for older stability-oriented kernels, RHEL or Debian is probably THE version to care about. You might also be interested in special-environment-kernels, such as non x86-kernels, in which case you're probably more interested in the central repo for that architecture, which is rarely Linuses. Also, IIRC, hard and soft realtime-enthusiasts neither looks at linuses tree first. Above all, in the Linux-kernel, there is not much of "centralised planning". Linus doesn't call to a big planning-meeting quarterly to set up specific milestones for the next kernel release, but in the beginning of each cycle, he is spammed with things already developed independently, scratching someones itch. He then cherry-picks the things that has got good reviews and are interesting for where he wants to go with the kernel. That is not to say that there aren't a lot of coordination and communication, but there isn't a clear centralized authority steering development in the same ways as in many other projects. The bottom line is, many projects, even ones using DVCS, are often centrally organized. However, the Linux kernel is clear evidence it is not the only project model that works.

Yeah, that's true. Some projects, the Linux kernel being one of the best examples, are more distributed in nature than not, in actual organizational terms. But projects like that are (and will remain) in the minority, a minority which is probably a very, very small. -- Bruno Medeiros - Software Engineer
Feb 17 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Bruno Medeiros wrote:
 but seriously, even if I am 
 connected to the Internet I cannot code with my laptop only, I need it 
 connected to a monitor, as well as a mouse, (and preferably a keyboard 
 as well).

I found I can't code on my laptop anymore; I am too used to and needful of a large screen.
Feb 11 2011
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 11/02/2011 23:30, Walter Bright wrote:
 Bruno Medeiros wrote:
 but seriously, even if I am connected to the Internet I cannot code
 with my laptop only, I need it connected to a monitor, as well as a
 mouse, (and preferably a keyboard as well).

I found I can't code on my laptop anymore; I am too used to and needful of a large screen.

Yeah, that was my point as well. The laptop monitor is too small for coding, (unless one has a huge laptop). -- Bruno Medeiros - Software Engineer
Feb 16 2011
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 06/02/2011 14:17, Ulrik Mikaelsson wrote:
 2011/2/4 Bruno Medeiros<brunodomedeiros+spam com.gmail>:
 Well, like I said, my concern about size is not so much disk space, but the
 time to make local copies of the repository, or cloning it from the internet
 (and the associated transfer times), both of which are not neglectable yet.
 My project at work could easily have gone to 1Gb of repo size if in the last
 year or so it has been stored on a DVCS! :S

 I hope this gets addressed at some point. But I fear that the main
 developers of both Git and Mercurial may be too "biased" to experience
 projects which are typically somewhat small in size, in terms of bytes
 (projects that consist almost entirely of source code).
 For example, in UI applications it would be common to store binary data
 (images, sounds, etc.) in the source control. The other case is what I
 mentioned before, wanting to store dependencies together with the project
 (in my case including the javadoc and source code of the dependencies - and
 there's very good reasons to want to do that).

I think the storage/bandwidth requirements of DVCS:s are very often exagerated, especially for text, but also somewhat for blobs. * For text-content, the compression of archives reduces them to, perhaps, 1/5 of their original size? - That means, that unless you completely rewrite a file 5 times during the course of a project, simple per-revision-compression of the file will turn out smaller, than the single uncompressed base-file that subversion transfers and stores. - The delta-compression applied ensures small changes does not count as a "rewrite". * For blobs, the archive-compression may not do as much, and they certainly pose a larger challenge for storing history, but: - AFAIU, at least git delta-compresses even binaries so even changes in them might be slightly reduced (dunno about the others) - I think more and more graphics are today are written in SVG? - I believe, for most projects, audio-files are usually not changed very often, once entered a project? Usually existing samples are simply copied in? * For both binaries and text, and for most projects, the latest revision is usually the largest. (Projects usually grow over time, they don't consistently shrink) I.E. older revisions are, compared to current, much much smaller, making the size of old history smaller compared to the size of current history. Finally, as a test, I tried checking out the last version of druntime from SVN and compare it to git (AFICT, history were preserved in the git-migration), the results were about what I expected. Checking out trunk from SVN, and the whole history from git: SVN: 7.06 seconds, 5,3 MB on disk Git: 2.88 seconds, 3.5 MB on disk Improvement Git/SVN: time reduced by 59%, space reduced by 34%. I did not measure bandwidth, but my guess is it is somewhere between the disk- and time- reductions. Also, if someone has an example of a recently converted repository including some blobs it would make an interesting experiment to repeat. Regards / Ulrik ----- ulrik ulrik ~/p/test> time svn co http://svn.dsource.org/projects/druntime/trunk druntime_svn ... 0.26user 0.21system 0:07.06elapsed 6%CPU (0avgtext+0avgdata 47808maxresident)k 544inputs+11736outputs (3major+3275minor)pagefaults 0swaps ulrik ulrik ~/p/test> du -sh druntime_svn 5,3M druntime_svn ulrik ulrik ~/p/test> time git clone git://github.com/D-Programming-Language/druntime.git druntime_git ... 0.26user 0.06system 0:02.88elapsed 11%CPU (0avgtext+0avgdata 14320maxresident)k 3704inputs+7168outputs (18major+1822minor)pagefaults 0swaps ulrik ulrik ~/p/test> du -sh druntime_git/ 3,5M druntime_git/

Yes, Brad had posted some statistics of the size of the Git repositories for dmd, druntime, and phobos, and yes, they are pretty small. Projects which contains practically only source code, and little to no binary data are unlikely to grow much and repo size ever be a problem. But it might not be the case for other projects (also considering that binary data is usually already well compressed, like .zip, .jpg, .mp3, .ogg, etc., so VCS compression won't help much). It's unlikely you will see converted repositories with a lot of changing blob data. DVCS, at the least in the way they work currently, simply kill this workflow/organization-pattern. I very much suspect this issue will become more important as time goes on - a lot of people are still new to DVCS and they still don't realize the full implications of that architecture with regards to repo size. Any file you commit will add to the repository size *FOREVER*. I'm pretty sure we haven't heard the last word on the VCS battle, in that in a few years time people are *again* talking about and switching to another VCS :( . Mark these words. (The only way this is not going to happen is if Git or Mercurial are able to address this issue in a satisfactory way, which I'm not sure is possible or easy) -- Bruno Medeiros - Software Engineer
Feb 09 2011
next sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bruno Medeiros wrote:
 Yes, Brad had posted some statistics of the size of the Git repositorie=

 for dmd, druntime, and phobos, and yes, they are pretty small.
 Projects which contains practically only source code, and little to no
 binary data are unlikely to grow much and repo size ever be a problem.
 But it might not be the case for other projects (also considering that
 binary data is usually already well compressed, like .zip, .jpg, .mp3,
 .ogg, etc., so VCS compression won't help much).
=20
 It's unlikely you will see converted repositories with a lot of changin=

 blob data. DVCS, at the least in the way they work currently, simply
 kill this workflow/organization-pattern.
 I very much suspect this issue will become more important as time goes
 on - a lot of people are still new to DVCS and they still don't realize=

 the full implications of that architecture with regards to repo size.
 Any file you commit will add to the repository size *FOREVER*. I'm
 pretty sure we haven't heard the last word on the VCS battle, in that i=

 a few years time people are *again* talking about and switching to
 another VCS :( . Mark these words. (The only way this is not going to
 happen is if Git or Mercurial are able to address this issue in a
 satisfactory way, which I'm not sure is possible or easy)
=20

issue. See for example: http://wiki.netbeans.org/HgExternalBinaries or http://mercurial.selenic.com/wiki/BigfilesExtension I do not know how well they perform in practice. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Feb 09 2011
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 09/02/2011 23:02, Ulrik Mikaelsson wrote:
 2011/2/9 Bruno Medeiros<brunodomedeiros+spam com.gmail>:
 It's unlikely you will see converted repositories with a lot of changing
 blob data. DVCS, at the least in the way they work currently, simply kill
 this workflow/organization-pattern.
 I very much suspect this issue will become more important as time goes on -
 a lot of people are still new to DVCS and they still don't realize the full
 implications of that architecture with regards to repo size. Any file you
 commit will add to the repository size *FOREVER*. I'm pretty sure we haven't
 heard the last word on the VCS battle, in that in a few years time people
 are *again* talking about and switching to another VCS :( . Mark these
 words. (The only way this is not going to happen is if Git or Mercurial are
 able to address this issue in a satisfactory way, which I'm not sure is
 possible or easy)

You don't happen to know about any projects of this kind in any other VCS that can be practically tested, do you?

You mean a project like that, hosted in Subversion or CVS (so that you can convert it to Git/Mercurial and see how it is in terms of repo size)? I don't know any of the top of my head, except the one in my job, but naturally it is commercial and closed-source so I can't share it. I'm cloning the Mozilla Firefox repo right now, I'm curious how big it is. ( https://developer.mozilla.org/en/Mozilla_Source_Code_%28Mercurial%29) But other than that, what exactly do you want to test? There is no specific thing to test, if you add a binary file (from a format that is already compressed, like zip, jar, jpg, etc.) of size X, you will increase the repo size by X bytes forever. There is no other way around it. (Unless on Git you rewrite the history on the repo, which doubtfully will ever be allowed on central repositories) -- Bruno Medeiros - Software Engineer
Feb 11 2011
parent reply Jean Crystof <a a.a> writes:
Bruno Medeiros Wrote:

 On 09/02/2011 23:02, Ulrik Mikaelsson wrote:
 2011/2/9 Bruno Medeiros<brunodomedeiros+spam com.gmail>:
 It's unlikely you will see converted repositories with a lot of changing
 blob data. DVCS, at the least in the way they work currently, simply kill
 this workflow/organization-pattern.
 I very much suspect this issue will become more important as time goes on -
 a lot of people are still new to DVCS and they still don't realize the full
 implications of that architecture with regards to repo size. Any file you
 commit will add to the repository size *FOREVER*. I'm pretty sure we haven't
 heard the last word on the VCS battle, in that in a few years time people
 are *again* talking about and switching to another VCS :( . Mark these
 words. (The only way this is not going to happen is if Git or Mercurial are
 able to address this issue in a satisfactory way, which I'm not sure is
 possible or easy)

You don't happen to know about any projects of this kind in any other VCS that can be practically tested, do you?

You mean a project like that, hosted in Subversion or CVS (so that you can convert it to Git/Mercurial and see how it is in terms of repo size)? I don't know any of the top of my head, except the one in my job, but naturally it is commercial and closed-source so I can't share it. I'm cloning the Mozilla Firefox repo right now, I'm curious how big it is. ( https://developer.mozilla.org/en/Mozilla_Source_Code_%28Mercurial%29) But other than that, what exactly do you want to test? There is no specific thing to test, if you add a binary file (from a format that is already compressed, like zip, jar, jpg, etc.) of size X, you will increase the repo size by X bytes forever. There is no other way around it. (Unless on Git you rewrite the history on the repo, which doubtfully will ever be allowed on central repositories)

One thing we've done at work with game asset files is we put them in a separate repository and to conserve space we use a cleaned branch as a base for work repository. The "graph" below shows how it works initial state -> alpha1 -> alpha2 -> beta1 -> internal rev X -> internal rev X+1 -> internal rev X+2 -> ... -> internal rev X+n -> beta2 Now we have a new beta2. What happens next is we take a snapshot copy of the state of beta2, go back to beta1, create a new branch and "paste" the snapshot there. Now we move the old working branch with internal revisions to someplace safe and start using this as a base. And the work continues with this: initial state -> alpha1 -> alpha2 -> beta1 -> beta2 > internal rev X+n+1 -> ... The repository size won't become a problem with text / source code. Since you're a SVN advocate, please explain how well it works with 2500 GB of asset files?
Feb 11 2011
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 11/02/2011 13:14, Jean Crystof wrote:
 Since you're a SVN advocate, please explain how well it works with 2500 GB of
asset files?

I'm not an SVN advocate. I have started using DVCSs over Subversion, and generally I agree they are better, but what I'm saying is that they are not all roses... it is not a complete win-win, there are a few important cons, like this one. -- Bruno Medeiros - Software Engineer
Feb 16 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, February 01, 2011 15:07:58 Walter Bright wrote:
 Bruno Medeiros wrote:
 A more serious issue that I learned (or rather forgotten about before
 and remembered now) is the whole DVCSes keep the whole repository
 history locally aspect, which has important ramifications. If the
 repository is big, although disk space may not be much of an issue,

I still find myself worrying about disk usage, despite being able to get a 2T drive these days for under a hundred bucks. Old patterns of thought die hard.

And some things will likely _always_ make disk usage a concern. Video would be a good example. If you have much video, even with good compression, it's going to take up a lot of space. Granted, there are _lots_ of use cases which just don't take up enough disk space to matter anymore, but you can _always_ find ways to use up disk space. Entertainingly, a fellow I know had a friend who joked that he could always hold all of his data in a shoebox. Originally, it was punch cards. Then it was 5 1/4" floppy disks. Then it was 3 1/2" floppy disks. Then it was CDs. Etc. Storage devices keep getting bigger and bigger, but we keep finding ways to fill them... - Jonathan M Davis
Feb 01 2011
prev sibling next sibling parent Travis Boucher <boucher.travis gmail.com> writes:
On 01/06/11 17:55, Vladimir Panteleev wrote:
 Disclaimer: I use Git, and avoid Mercurial if I can mainly because I
 don't want to learn another VCS. Nevertheless, I tried to be objective
 above.
 As I mentioned on IRC, I strongly believe this must be a fully-informed
 decision, since changing VCSes again is unrealistic once it's done.

Recently I have been using mercurial (bitbucket). I have used git previously, and subversion alot. The question I think is less of git vs. mercurial and more of (git|mercurial) vs. (subversion) and even more (github|bitbucket) vs. dsource. I like dsource alot, however it doesn't compare feature wise to github & bitbucket. The only argument feature wise is forums, and in reality we already have many places to offer/get support for D and D projects other than the dsource forums (newsgroups & irc for example). Another big issue I have with dsource is that its hard to find active projects and projects that have been dead (sometimes for 5+ years). The 'social coding' networks allow projects to be easily revived in the case they do die. Personally I don't care which is used (git|mercurial, github|bitbucket), as long as we find a better way of managing the code, and a nice way of doing experimental things and having a workflow to have those experimental things pulled into the official code bases. dsource has served us well, and could still be a useful tool (maybe have it index D stuff from (github|bitbucket)?), but its time to start using some of the other, better, tools out there.
Jan 06 2011
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-01-06 19:55:10 -0500, "Vladimir Panteleev" 
<vladimir thecybershadow.net> said:

 2) One-click forking - you can easily publish improvements that are 
 easily  discoverable to people interested in the project. (This 
 practically  guarantees that an open-source project will never hit a 
 dead end, as long  as some people are interested in it - both 
 occasional patches and  maintained forks are easily discoverable.)

Easy forking is nice, but it could be a problem in our case. The license for the backend is not open-source enough for someone to republish it (in a separate own repo) without Walter's permission. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 06 2011
next sibling parent Travis Boucher <boucher.travis gmail.com> writes:
On 01/06/11 18:30, Vladimir Panteleev wrote:
 On Fri, 07 Jan 2011 03:17:50 +0200, Michel Fortin
 <michel.fortin michelf.com> wrote:

 Easy forking is nice, but it could be a problem in our case. The
 license for the backend is not open-source enough for someone to
 republish it (in a separate own repo) without Walter's permission.

I suggested elsewhere in this thread that the two must be separated first. I think it must be done anyway when moving to a DVCS, regardless of the specific one or which hosting site we'd use.

I agree, separating out the proprietary stuff has other interesting possibilities such as a D front end written in D and integration with IDEs and analysis tools. Of course all of this is possible now, but it'd make merging front end updates so much nicer.
Jan 06 2011
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-01-06 20:30:53 -0500, "Vladimir Panteleev" 
<vladimir thecybershadow.net> said:

 On Fri, 07 Jan 2011 03:17:50 +0200, Michel Fortin  
 <michel.fortin michelf.com> wrote:
 
 Easy forking is nice, but it could be a problem in our case. The 
 license  for the backend is not open-source enough for someone to 
 republish it  (in a separate own repo) without Walter's permission.

I suggested elsewhere in this thread that the two must be separated first. I think it must be done anyway when moving to a DVCS, regardless of the specific one or which hosting site we'd use.

Which means that we need another solution for the backend, and if that solution isn't too worthless it could be used to host the other parts too and keep them together. That said, wherever the repositories are kept, nothing prevents them from being automatically mirrored on github (or anywhere else) by simply adding a post-update hook in the main repository. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 06 2011
parent reply David Nadlinger <see klickverbot.at> writes:
On 1/7/11 2:43 AM, Michel Fortin wrote:
 Which means that we need another solution for the backend, and if that
 solution isn't too worthless it could be used to host the other parts
 too and keep them together.

Just to be sure: You did mean »together« as in »separate repositories on the same hosting platform«, right? I don't even think we necessarily can't use GitHub or the likes for the backend, we'd just need permission from Walter to redistribute the sources through that repository, right? It's been quite some time since I had a look at the backend license though… David
Jan 06 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message 
news:op.vow11fqdtuzx1w cybershadow.mshome.net...
 On Fri, 07 Jan 2011 04:09:04 +0200, Andrej Mitrovic 
 <andrej.mitrovich gmail.com> wrote:

 I don't think git really needs MSYS? I mean I've just installed git
 again and it does have it's own executable runnable from the console.

MSysGit comes with its own copy of MSys. It's pretty transparent to the user, though.

That might not be too bad then if it's all packaged well. The main problem with MSYS/MinGW is just getting the damn thing downloaded, installed and running properly. Do you need to actually use the MSYS/MinGW command-line, or is that all hidden away and totally behind-the-scenes?
Jan 06 2011
parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Nick Sabalausky Wrote:

 "Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message 
 news:op.vow11fqdtuzx1w cybershadow.mshome.net...
 On Fri, 07 Jan 2011 04:09:04 +0200, Andrej Mitrovic 
 <andrej.mitrovich gmail.com> wrote:

 I don't think git really needs MSYS? I mean I've just installed git
 again and it does have it's own executable runnable from the console.

MSysGit comes with its own copy of MSys. It's pretty transparent to the user, though.

That might not be too bad then if it's all packaged well. The main problem with MSYS/MinGW is just getting the damn thing downloaded, installed and running properly. Do you need to actually use the MSYS/MinGW command-line, or is that all hidden away and totally behind-the-scenes?

I am able to run git commands from powershell. I ran a single install program that made it all happen for me. You can run what it calls "git bash" to open mingw.
Jan 06 2011
parent "Nick Sabalausky" <a a.a> writes:
"Jesse Phillips" <jessekphillips+D gmail.com> wrote in message 
news:ig61ni$frh$1 digitalmars.com...
 Nick Sabalausky Wrote:

 "Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message
 news:op.vow11fqdtuzx1w cybershadow.mshome.net...
 On Fri, 07 Jan 2011 04:09:04 +0200, Andrej Mitrovic
 <andrej.mitrovich gmail.com> wrote:

 I don't think git really needs MSYS? I mean I've just installed git
 again and it does have it's own executable runnable from the console.

MSysGit comes with its own copy of MSys. It's pretty transparent to the user, though.

That might not be too bad then if it's all packaged well. The main problem with MSYS/MinGW is just getting the damn thing downloaded, installed and running properly. Do you need to actually use the MSYS/MinGW command-line, or is that all hidden away and totally behind-the-scenes?

I am able to run git commands from powershell. I ran a single install program that made it all happen for me. You can run what it calls "git bash" to open mingw.

I just tried the msysgit installer that Andrej linked to. I didn't try to use or create any repository, but everthing seems to work great so far. Painless installer, Git GUI launches fine, "git" works from my ordinary windows command line, and I never had to touch MSYS directly in any way. Nice!
Jan 07 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-01-07 03:31, Andrej Mitrovic wrote:
 On 1/7/11, Vladimir Panteleev<vladimir thecybershadow.net>  wrote:
 On Fri, 07 Jan 2011 04:09:04 +0200, Andrej Mitrovic
 <andrej.mitrovich gmail.com>  wrote:

 I don't think git really needs MSYS? I mean I've just installed git
 again and it does have it's own executable runnable from the console.

MSysGit comes with its own copy of MSys. It's pretty transparent to the user, though.

Aye, but I didn't download that one, I got the one on the top here: https://code.google.com/p/msysgit/downloads/list?can=3 And if I put git.exe in it's own directory the only .dll it complains about is libiconv2.dll (well that, and some missing templates). Using these two alone seems to work fine.

Ever heard of TortoiseGit: http://code.google.com/p/tortoisegit/ -- /Jacob Carlborg
Jan 08 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message 
news:op.vowx58gqtuzx1w cybershadow.mshome.net...
 Git is expected to be slower on Windows, since it runs on top of 
 cygwin/msys.

I'd consider running under MSYS to be a *major* disadvantage. MSYS is barely usable garbage (and cygwin is just plain worthless).
Jan 06 2011
prev sibling parent reply Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:
 On 1/6/11 9:18 AM, Don wrote:
 Walter Bright wrote:
 Nick Sabalausky wrote:
 "Caligo" <iteronvexor gmail.com> wrote in message
 news:mailman.451.1294306555.4748.digitalmars-d puremagic.com...
 On Thu, Jan 6, 2011 at 12:28 AM, Walter Bright
 <newshound2 digitalmars.com>wrote:

 That's pretty much what I'm afraid of, losing my grip on how the 
 whole
 thing works if there are multiple dmd committers.

 Perhaps using a modern SCM like Git might help? Everyone could have
 (and

or one of the managers would then review the changes and pull and merge with the main branch. It works great; just checkout out Rubinius on Github to see what I mean: https://github.com/evanphx/rubinius

I'm not sure I see how that's any different from everyone having "create and submit a patch" rights, and then having Walter or one of the managers review the changes and merge/patch with the main branch.

I don't, either.

There's no difference if you're only making one patch, but once you make more, there's a significant difference. I can generally manage to fix about five bugs at once, before they start to interfere with each other. After that, I have to wait for some of the bugs to be integrated into the trunk, or else start discarding changes from my working copy. Occasionally I also use my own DMD local repository, but it doesn't work very well (gets out of sync with the trunk too easily, because SVN isn't really set up for that development model). I think that we should probably move to Mercurial eventually. I think there's potential for two benefits: (1) quicker for you to merge changes in; (2) increased collaboration between patchers. But due to the pain in changing the developement model, I don't think it's a change we should make in the near term.

What are the advantages of Mercurial over git? (git does allow multiple branches.) Andrei

Essentially political and practical rather than technical. Mercurial doesn't have the blatant hostility to Windows that is evident in git. It also doesn't have the blatant hostility to svn (in fact, it tries hard to ease the transition). Technically, I don't think there's much difference between git and Mercurical, compared to how different they are from svn.
Jan 06 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday 07 January 2011 03:33:48 Lars T. Kyllingstad wrote:
 On Fri, 07 Jan 2011 08:53:06 +0100, Don wrote:
 Andrei Alexandrescu wrote:
 What are the advantages of Mercurial over git? (git does allow multiple
 branches.)
 
 Andrei

Essentially political and practical rather than technical. Mercurial doesn't have the blatant hostility to Windows that is evident in git. It also doesn't have the blatant hostility to svn (in fact, it tries hard to ease the transition).

I don't think Git's SVN hostility is a problem in practice. AFAIK there are tools (git-svn comes to mind) that can transfer the contents of an SVN repository, with full commit history and all, to a Git repo. Also, it will only have to be done once, so that shouldn't weigh too heavily on the decision.
 Technically, I don't think there's much difference between git and
 Mercurical, compared to how different they are from svn.

Then my vote goes to Git, simply because that's what I'm familiar with. -Lars

Well, you get the full commit history if you use git-svn to commit to an svn repository. I'm not sure it deals with svn branches very well though, since svn treats those as separate files, and so each branch is actually a separate set of files, and I don't believe that git will consider them to be the same. However, since I always just use git-svn on the trunk of whatever svn repository I'm dealing with, I'm not all that experienced with dealing with how svn branches look in a git repository's history. And it may be that there's a way to specifically import an svn repository in a manner which makes all of those branches look as a single set of files to git. I don't know. But on the whole, converting from subversion to git is pretty easy. We technically use svn at work, but I always just use git-svn. Life is much more pleasant that way. - Jonathan M Davis
Jan 07 2011
parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Jonathan M Davis Wrote:

 Well, you get the full commit history if you use git-svn to commit to an svn 
 repository. I'm not sure it deals with svn branches very well though, since
svn 
 treats those as separate files, and so each branch is actually a separate set
of 
 files, and I don't believe that git will consider them to be the same.
However, 
 since I always just use git-svn on the trunk of whatever svn repository I'm 
 dealing with, I'm not all that experienced with dealing with how svn branches 
 look in a git repository's history. And it may be that there's a way to 
 specifically import an svn repository in a manner which makes all of those 
 branches look as a single set of files to git. I don't know. But on the whole, 
 converting from subversion to git is pretty easy. We technically use svn at 
 work, but I always just use git-svn. Life is much more pleasant that way.
 
 - Jonathan M Davis

You can have git-svn import the standard svn layout. This will than import the tags and branches. And best I can tell, the reason it takes so long to do this is because it is analyzing each branch to see where it occurred, and then making the proper branches as it would be in Git. You can specify your own layout if your branches aren't set up like a standard svn.
Jan 07 2011
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Fri, 07 Jan 2011 03:42:33 -0800, Jonathan M Davis wrote:

 On Friday 07 January 2011 03:33:48 Lars T. Kyllingstad wrote:
 On Fri, 07 Jan 2011 08:53:06 +0100, Don wrote:
 Andrei Alexandrescu wrote:
 What are the advantages of Mercurial over git? (git does allow
 multiple branches.)
 
 Andrei

Essentially political and practical rather than technical. Mercurial doesn't have the blatant hostility to Windows that is evident in git. It also doesn't have the blatant hostility to svn (in fact, it tries hard to ease the transition).

I don't think Git's SVN hostility is a problem in practice. AFAIK there are tools (git-svn comes to mind) that can transfer the contents of an SVN repository, with full commit history and all, to a Git repo. Also, it will only have to be done once, so that shouldn't weigh too heavily on the decision.
 Technically, I don't think there's much difference between git and
 Mercurical, compared to how different they are from svn.

Then my vote goes to Git, simply because that's what I'm familiar with. -Lars

Well, you get the full commit history if you use git-svn to commit to an svn repository. I'm not sure it deals with svn branches very well though, [...]

Here's a page that deals with importing an SVN repo in git: http://help.github.com/svn-importing/ Actually, based on that page, it seems Github can automatically take care of the whole transfer for us, if we decide to set up there. -Lars
Jan 07 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Don wrote:
 Mercurial doesn't have the blatant hostility to Windows that is evident 
 in git. It also doesn't have the blatant hostility to svn (in fact, it 
 tries hard to ease the transition).

I've been using git on a couple small projects, and I find that I have to transfer the files to Linux in order to check them in to git.
Jan 07 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:ig7mee$1r10$1 digitalmars.com...
 Don wrote:
 Mercurial doesn't have the blatant hostility to Windows that is evident 
 in git. It also doesn't have the blatant hostility to svn (in fact, it 
 tries hard to ease the transition).

I've been using git on a couple small projects, and I find that I have to transfer the files to Linux in order to check them in to git.

When I installed msysgit I got Git entires added to explorer's right-click menu. Do those not work?
Jan 07 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Vladimir Panteleev wrote:
 On Fri, 07 Jan 2011 20:33:42 +0200, Walter Bright 
 <newshound2 digitalmars.com> wrote:
 
 Don wrote:
 Mercurial doesn't have the blatant hostility to Windows that is 
 evident in git. It also doesn't have the blatant hostility to svn (in 
 fact, it tries hard to ease the transition).

I've been using git on a couple small projects, and I find that I have to transfer the files to Linux in order to check them in to git.

Could you please elaborate? A lot of people are using Git on Windows without any problems.

No download for Windows from the git site.
Jan 07 2011
next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Walter Bright Wrote:

 Vladimir Panteleev wrote:
 On Fri, 07 Jan 2011 20:33:42 +0200, Walter Bright 
 <newshound2 digitalmars.com> wrote:
 
 Don wrote:
 Mercurial doesn't have the blatant hostility to Windows that is 
 evident in git. It also doesn't have the blatant hostility to svn (in 
 fact, it tries hard to ease the transition).

I've been using git on a couple small projects, and I find that I have to transfer the files to Linux in order to check them in to git.

Could you please elaborate? A lot of people are using Git on Windows without any problems.

No download for Windows from the git site.

Direct: http://code.google.com/p/msysgit/downloads/detail?name=Git-1.7.3.1-preview20101002.exe&can=2&q= Website: http://code.google.com/p/msysgit/
Jan 07 2011
prev sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 1/7/11 10:21 PM, Walter Bright wrote:
 No download for Windows from the git site.

Are you deliberately trying to make yourself look ignorant? Guess what's right at the top of http://git-scm.com/… David
Jan 07 2011
next sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 1/7/11 10:31 PM, David Nadlinger wrote:
 Are you deliberately trying to make yourself look ignorant? Guess what's
 right at the top of http://git-scm.com/

I just realized that this might have sounded a bit too harsh, there was no offense intended. I am just somewhat annoyed by the frequency easy-to-research facts are misquoted at this newsgroup right now, as well as how this could influence the way D and the D community are perceived as a whole. David
Jan 07 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
David Nadlinger:

 I just realized that this might have sounded a bit too harsh, there was 
 no offense intended.

Being gentle and not offensive is Just Necessary [TM] in a newsgroup like this. On the other hand Walter is a pretty adult person so I think he's not offended. Bye, bearophile
Jan 07 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/7/11 5:49 PM, bearophile wrote:
 David Nadlinger:

 I just realized that this might have sounded a bit too harsh, there was
 no offense intended.

Being gentle and not offensive is Just Necessary [TM] in a newsgroup like this. On the other hand Walter is a pretty adult person so I think he's not offended. Bye, bearophile

Well he is adult all right. Pretty? Maybt not that much :o). Andrei
Jan 07 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Well he is adult all right. Pretty? Maybt not that much :o).

Hawt? Perhaps!
Jan 07 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
David Nadlinger wrote:
 On 1/7/11 10:21 PM, Walter Bright wrote:
 No download for Windows from the git site.

Are you deliberately trying to make yourself look ignorant? Guess what's right at the top of http://git-scm.com/

So it is. The last time I looked, it wasn't there.
Jan 07 2011
prev sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 1/7/11 8:53 AM, Don wrote:
 What are the advantages of Mercurial over git? (git does allow
 multiple branches.)

 Andrei

Essentially political and practical rather than technical. […]

By the way, I just stumbled upon this page presenting arguments in favor of Git, which seems about as objective to me as it will probably get: http://whygitisbetterthanx.com/ Obviously, this site is biased in the sense that it doesn't mention possible arguments against Git – do you know of any similar collections for other DVCS? David
Jan 08 2011
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

David Nadlinger wrote:
 On 1/7/11 8:53 AM, Don wrote:
 What are the advantages of Mercurial over git? (git does allow
 multiple branches.)

 Andrei

Essentially political and practical rather than technical. [=E2=80=A6=


=20
 By the way, I just stumbled upon this page presenting arguments in favo=

 of Git, which seems about as objective to me as it will probably get:
 http://whygitisbetterthanx.com/
=20
 Obviously, this site is biased in the sense that it doesn't mention
 possible arguments against Git =E2=80=93 do you know of any similar col=

 for other DVCS?
=20

* Cheap local branching Available in Mercurial with the LocalbranchExtension. * Git is fast Probably true on Linux, not so on Windows. The speed is acceptable for most operations, but it is slower than Mercurial. * Staging area Could actually be seen as a drawback since it adds extra complexity. Depending on your workflow, most of the use cases can be handled more easily in Mercurial with the crecord extension. * GitHub Bitbucket. * Easy to learn Mouahahahahahahah! The other points are true, but they are also applicable to any DVCS. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jan 09 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Russel Winder wrote:
 Pity, because using one of Mercurial, Bazaar or Git instead of
 Subversion is likely the best and fastest way of getting more quality
 contributions to review.  Although only anecdotal in every case where a
 team has switched to DVCS from CVCS -- except in the case of closed
 projects, obviously -- it has opened things up to far more people to
 provide contributions.  Subversion is probably now the single biggest
 barrier to getting input on system evolution.

A couple months back, I did propose moving to git on the dmd internals mailing list, and nobody was interested. One thing I like a lot about svn is this: http://www.dsource.org/projects/dmd/changeset/291 where the web view will highlight the revision's changes. Does git or mercurial do that? The other thing I like a lot about gif is it sends out emails for each checkin. One thing I would dearly like is to be able to merge branches using meld. http://meld.sourceforge.net/
Jan 06 2011
next sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Walter Bright Wrote:

 Russel Winder wrote:
 Pity, because using one of Mercurial, Bazaar or Git instead of
 Subversion is likely the best and fastest way of getting more quality
 contributions to review.  Although only anecdotal in every case where a
 team has switched to DVCS from CVCS -- except in the case of closed
 projects, obviously -- it has opened things up to far more people to
 provide contributions.  Subversion is probably now the single biggest
 barrier to getting input on system evolution.

A couple months back, I did propose moving to git on the dmd internals mailing list, and nobody was interested. One thing I like a lot about svn is this: http://www.dsource.org/projects/dmd/changeset/291

You mean this: https://github.com/braddr/dmd/commit/f1fde96227394f926da5841db4f0f4c608b2e7b2
 
 where the web view will highlight the revision's changes. Does git or
mercurial 
 do that? The other thing I like a lot about gif is it sends out emails for
each 
 checkin.
 
 One thing I would dearly like is to be able to merge branches using meld.
 
 http://meld.sourceforge.net/

Git does not have its own merge tool. You are free to use meld. Though there is gitmerge which can run meld as the merge tool.
Jan 06 2011
next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Jesse Phillips Wrote:

 where the web view will highlight the revision's changes. Does git or
mercurial 
 do that? The other thing I like a lot about gif is it sends out emails for
each 
 checkin.
 
 One thing I would dearly like is to be able to merge branches using meld.
 
 http://meld.sourceforge.net/

Git does not have its own merge tool. You are free to use meld. Though there is gitmerge which can run meld as the merge tool.

Just realized you probably meant more than just resolving conflicts. And what you might be interested in git cherry picking. I haven't done it myself and don't know if meld could be used for it.
Jan 06 2011
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-01-06 15:01:18 -0500, Jesse Phillips <jessekphillips+D gmail.com> said:

 Walter Bright Wrote:
 
 A couple months back, I did propose moving to git on the dmd internals mailing
 list, and nobody was interested.


I probably wasn't on the list at the time. I'm certainly interested, it'd certainly make it easier for me, as I'm using git locally to access that repo.
 One thing I like a lot about svn is this:
 
 http://www.dsource.org/projects/dmd/changeset/291

You mean this: https://github.com/braddr/dmd/commit/f1fde96227394f926da5841db4f0f4c608b2e7b2

That's
 

comes with a web interface that looks like this (pointing to a specific diff): <http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git/commitdiff/d7214dcb5be988a5c7d407f907c7e7e789872d24> Also when I want an overview with git I just type gitk on the command line to bring a window where I can browser the graph of forks, merges and commits and see the diff for each commit. Here's what gitk looks like: <http://michael-prokop.at/blog/img/gitk.png>
 where the web view will highlight the revision's changes. Does git or mercurial
 do that? The other thing I like a lot about gif is it sends out emails for each
 checkin.
 
 One thing I would dearly like is to be able to merge branches using meld.
 
 http://meld.sourceforge.net/

Git does not have its own merge tool. You are free to use meld. Though there is gitmerge which can run meld as the merge tool.

Looks like meld itself used git as it's repository. I'd be surprised if it doesn't work with git. :-) -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 06 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Michel Fortin wrote:
 On 2011-01-06 15:01:18 -0500, Jesse Phillips 
 <jessekphillips+D gmail.com> said:
 
 Walter Bright Wrote:

 A couple months back, I did propose moving to git on the dmd 
 internals mailing
 list, and nobody was interested.


I probably wasn't on the list at the time. I'm certainly interested, it'd certainly make it easier for me, as I'm using git locally to access that repo.
 One thing I like a lot about svn is this:

 http://www.dsource.org/projects/dmd/changeset/291

You mean this: https://github.com/braddr/dmd/commit/f1fde96227394f926da5841db4f0f4c608b2e7b2

That's

comes with a web interface that looks like this (pointing to a specific diff): <http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git/commitdiff/d7214dcb5be988a5c7d40 f907c7e7e789872d24>

Eh, that's inferior. The svn will will highlight what part of a line is different, rather than just the whole line.
 Looks like meld itself used git as it's repository. I'd be surprised if 
 it doesn't work with git. :-)

I use git for other projects, and meld doesn't work with it.
Jan 06 2011
parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Walter Bright wrote:

 Looks like meld itself used git as it's repository. I'd be surprised if
 it doesn't work with git. :-)

I use git for other projects, and meld doesn't work with it.

What version are you on? I'm using 1.3.2 and its supports git and mercurial (also committing from inside meld & stuff, I take it this is what you mean with supporting a vcs).
Jan 08 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Lutger Blijdestijn wrote:
 Walter Bright wrote:
 
 Looks like meld itself used git as it's repository. I'd be surprised if
 it doesn't work with git. :-)


What version are you on? I'm using 1.3.2 and its supports git and mercurial (also committing from inside meld & stuff, I take it this is what you mean with supporting a vcs).

The one that comes with: sudo apt-get meld 1.1.5.1
Jan 08 2011
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-01-08 15:36:39 -0500, Walter Bright <newshound2 digitalmars.com> said:

 Lutger Blijdestijn wrote:
 Walter Bright wrote:
 
 Looks like meld itself used git as it's repository. I'd be surprised if
 it doesn't work with git. :-)


What version are you on? I'm using 1.3.2 and its supports git and mercurial (also committing from inside meld & stuff, I take it this is what you mean with supporting a vcs).

The one that comes with: sudo apt-get meld 1.1.5.1

I know you had your reasons, but perhaps it's time for you upgrade to a more recent version of Ubuntu? That version is what comes with Hardy Heron (april 2008). <https://launchpad.net/ubuntu/+source/meld> Or you could download the latest version from meld's website and compile it yourself. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 08 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Michel Fortin wrote:
 I know you had your reasons, but perhaps it's time for you upgrade to a 
 more recent version of Ubuntu? That version is what comes with Hardy 
 Heron (april 2008).
 <https://launchpad.net/ubuntu/+source/meld>

I know. The last time I upgraded Ubuntu in place it f****d up my system so bad I had to wipe the disk and start all over. It still won't play videos correctly (the previous Ubuntu worked fine), the rhythmbox music player never worked again, it wiped out all my virtual boxes, I had to spend hours googling around trying to figure out how to reconfigure the display driver so the monitor worked again, etc. I learned my lesson! Yes, I'll eventually upgrade, but I'm not looking forward to it.
 Or you could download the latest version from meld's website and compile 
 it yourself.

Yeah, I could spend an afternoon doing that.
Jan 08 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Vladimir Panteleev wrote:
  From taking a quick look, I don't see meld's advantage over WinMerge 
 (other than being cross-platform).

Thanks for pointing me at winmerge. I've been looking for one to work on Windows.
Jan 08 2011
next sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Walter Bright wrote:
 Vladimir Panteleev wrote:
  From taking a quick look, I don't see meld's advantage over WinMerge
 (other than being cross-platform).

Thanks for pointing me at winmerge. I've been looking for one to work o=

 Windows.

I personally use kdiff3 [1] both on Linux and Windows. Jerome [1] http://kdiff3.sourceforge.net/ --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jan 09 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:igb5uo$26af$1 digitalmars.com...
 Vladimir Panteleev wrote:
  From taking a quick look, I don't see meld's advantage over WinMerge 
 (other than being cross-platform).

Thanks for pointing me at winmerge. I've been looking for one to work on Windows.

Beyond Compare and Ultra Compare
Jan 11 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Vladimir Panteleev wrote:
 On Sun, 09 Jan 2011 00:34:19 +0200, Walter Bright 
 <newshound2 digitalmars.com> wrote:
 
 Yeah, I could spend an afternoon doing that.

sudo apt-get build-dep meld wget http://ftp.gnome.org/pub/gnome/sources/meld/1.5/meld-1.5.0.tar.bz2 tar jxf meld-1.5.0.tar.bz2 cd meld-1.5.0 make sudo make install You're welcome ;)

Jan 08 2011
next sibling parent reply Christopher Nicholson-Sauls <ibisbasenji gmail.com> writes:
On 01/08/11 20:18, Walter Bright wrote:
 Vladimir Panteleev wrote:
 On Sun, 09 Jan 2011 00:34:19 +0200, Walter Bright
 <newshound2 digitalmars.com> wrote:

 Yeah, I could spend an afternoon doing that.

sudo apt-get build-dep meld wget http://ftp.gnome.org/pub/gnome/sources/meld/1.5/meld-1.5.0.tar.bz2 tar jxf meld-1.5.0.tar.bz2 cd meld-1.5.0 make sudo make install You're welcome ;)


I say you should consider moving away from *Ubuntu and to something more "developer-friendly" such as Gentoo, where the command to install meld is just: emerge meld ...done. And yes, that's an install from source. I just did it myself, and it took right at one minute. -- Chris N-S
Jan 09 2011
parent Christopher Nicholson-Sauls <ibisbasenji gmail.com> writes:
On 01/10/11 21:14, retard wrote:
 Sun, 09 Jan 2011 06:00:21 -0600, Christopher Nicholson-Sauls wrote:
 
 On 01/08/11 20:18, Walter Bright wrote:
 Vladimir Panteleev wrote:
 On Sun, 09 Jan 2011 00:34:19 +0200, Walter Bright
 <newshound2 digitalmars.com> wrote:

 Yeah, I could spend an afternoon doing that.

sudo apt-get build-dep meld wget http://ftp.gnome.org/pub/gnome/sources/meld/1.5/meld-1.5.0.tar.bz2 tar jxf meld-1.5.0.tar.bz2 cd meld-1.5.0 make sudo make install You're welcome ;)


I say you should consider moving away from *Ubuntu and to something more "developer-friendly" such as Gentoo, where the command to install meld is just: emerge meld ...done. And yes, that's an install from source. I just did it myself, and it took right at one minute.

Gentoo really needs a high-end computer to run fast.

Tell that to the twelve year old machine here in our living room, running latest Gentoo profile with KDE 4.x all with no problem. FWIW, the same meld
 takes 7 seconds to install on my ubuntu. That includes fetching the 
 package from the internet (1-2 seconds). Probably even faster on Arch.

Sure, and my wife's Kubuntu machine would probably do the same -- since *Ubuntu installs pre-compiled binaries (some packages are available as source, as I recall, but very few). I acknowledge that you disclaimed your statement with a "FWIW" but I have to say it isn't much of a comparison: pre-compiled binaries versus locally built from source. I only really brought up how long it took because of Walter's "spend an afternoon" comment anyhow, so really we both "win" in this case. ;) And yes, I'm an unashamed Gentoo advocate to begin with. Been using it as both server and personal desktop OS for years now. (Of course half or more of what I love about it is portage, which can be used with other distros -- and BSD! -- although I know nothing about how one sets that up.) -- Chris N-S
Jan 12 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 09 January 2011 04:00:21 Christopher Nicholson-Sauls wrote:
 On 01/08/11 20:18, Walter Bright wrote:
 Vladimir Panteleev wrote:
 On Sun, 09 Jan 2011 00:34:19 +0200, Walter Bright
 
 <newshound2 digitalmars.com> wrote:
 Yeah, I could spend an afternoon doing that.

sudo apt-get build-dep meld wget http://ftp.gnome.org/pub/gnome/sources/meld/1.5/meld-1.5.0.tar.bz2 tar jxf meld-1.5.0.tar.bz2 cd meld-1.5.0 make sudo make install You're welcome ;)

Thanks, I'll give it a try!

I say you should consider moving away from *Ubuntu and to something more "developer-friendly" such as Gentoo, where the command to install meld is just: emerge meld ...done. And yes, that's an install from source. I just did it myself, and it took right at one minute.

Yeah well, much as I like gentoo, if he didn't like dealing with the pain of an Ubuntu upgrade messing with his machine, I doubt that he'll be enamoured with having to keep figuring out how to fix his machine because one of the builds didn't work on an update in Gentoo. Gentoo definitely has some great stuff going for it, but you have to be willing to deal with fixing your machine on a semi- regular basis. Personally, I got sick of it and moved on. Currently, I use Arch, which is _way_ more friendly for building non-repo packages yourself or otherwise messing repo packages. You _can_ choose to build from source but don't _have_ to, and you get a rolling release like you effectively get with Gentoo. So, I'm much happier with Arch than I was with Gentoo. But regardless, there's no need to start an argument over distros. They all have their pros and cons, and everyone is going to prefer one over another. Still, Gentoo is one of those distros where you have to expect to work at maintaining your machine, whereas Ubuntu really isn't. So, I wouldn't normally recommend Gentoo to someone who's using Ubuntu unless they're specifically looking for something like Gentoo. - Jonathan M Davis
Jan 09 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I'm keeping my eye on BeyondCompare. But it's not free. It's $80 for
the dual platform Linux+Windows and the Pro version which features
3-way merge. It's customization options are great though. There's a
trial version over at http://www.scootersoftware.com/ if you want to
give it a spin.
Jan 09 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/9/11, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 I'm keeping my eye on BeyondCompare. But it's not free. It's $80 for
 the dual platform Linux+Windows and the Pro version which features
 3-way merge. It's customization options are great though. There's a
 trial version over at http://www.scootersoftware.com/ if you want to
 give it a spin.

There's at least one caveat though: it doesn't natively support D files. So the best thing to do is add *.d and *.di as file masks for its C++ parser.
Jan 09 2011
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Jonathan M Davis wrote:
 Of course, I'd have got nuts having an installation as old as yours appears to 
 be,

I think it's less than a year old.
Jan 08 2011
prev sibling next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 09.01.2011 12:16, schrieb Russel Winder:
 Debian Testing is really a rolling release but it tends to be behind
 Ubuntu is some versions of things and ahead in others.  Also Ubuntu has
 non-free stuff that is forbidden on Debian.  Not to mention the F$$$F$$
 fiasco!

That's why debian has contrib and non-free repos. Ok, lame and libdvdcss are missing, but can be easily obtained from debian-multimedia.org (the latter is missing in ubuntu as well). What's F$$$F$$? Cheers, - Daniel
Jan 09 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 09.01.2011 22:16, schrieb Vladimir Panteleev:
 On Sun, 09 Jan 2011 21:02:13 +0200, Daniel Gibson <metalcaedes gmail.com>
wrote:

 What's F$$$F$$?

FireFox/IceWeasel: http://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project

Oh that. I couldn't care less if my browser is called Firefox or Iceweasel. Firefox plugins/extensions work with Iceweasel without any problems and I'm not aware of any issues caused by that rebranding. Also you're free to not install Iceweasel and install the Firefox binaries from mozilla.com. (The same is true for Thunderbird/Icedove) Cheers, - Daniel
Jan 09 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
 Ubuntu has a menu entry for "restricted drivers". It provides support for 
 both ATI/AMD (Radeon 8500 or better, appeared in 1998 or 1999!) and 
 NVIDIA cards (Geforce 256 or better, appeared in 1999!) and I think it 
 automatically suggests (a pop-up window) correct drivers in the latest 
 releases right after the first install.
 
 Intel chips are automatically supported by the open source drivers. VIA 
 and S3 may or may not work out of the box. I'm just a bit curious to know 
 what GPU you have? If it's some ancient VLB (vesa local bus) or ISA card, 
 I can donate $15 for buying one that uses AGP or PCI Express.
 
 Ubuntu doesn't support all video formats out of the box, but the media 
 players and browsers automatically suggest loading missing drivers. At 
 least in the 3 or 4 latest releases. Maybe the problem isn't the encoder, 
 it might be the Linux incompatible web site.

My mobo is an ASUS M2A-VM. No graphics cards, or any other cards plugged into it. It's hardly weird or wacky or old (it was new at the time I bought it to install Ubuntu). My display is 1920 x 1200. That just seems to cause grief for Ubuntu. Windows has no issues at all with it.
 Or you could download the latest version from meld's website and
 compile it yourself.


Another one of these jokes? Probably one of the best compiler authors in the whole world uses a whole afternoon doing something (compiling a program)

On the other hand, I regularly get emails from people with 10 years of coding experience who are flummoxed by a "symbol not defined" message from the linker. :-)
 that total Linux noobs do in less than 30 minutes with the help 
 of Google search.

Yeah, I've spent a lot of time googling for solutions to problems with Linux. You know what? I get pages of results from support forums - every solution is different and comes with statements like "seems to work", "doesn't work for me", etc. The advice is clearly from people who do not know what they are doing, and randomly stab at things, and these are the first page of google results.
Jan 11 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrej Mitrovic wrote:
 That's my biggest problem with Linux. Having technical problems is not
 the issue, finding the right solution in the sea of forum posts is the
 problem.

The worst ones begin with "you might try this..." or "I think this might work, but YMMV..." How do these wind up being the top ranked results by google? Who embeds links to that stuff? My experience with Windows is, like yours, the opposite. The top ranked result will be correct and to the point. No weasel wording.
Jan 11 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 11.01.2011 22:36, schrieb Walter Bright:
 Andrej Mitrovic wrote:
 That's my biggest problem with Linux. Having technical problems is not
 the issue, finding the right solution in the sea of forum posts is the
 problem.

The worst ones begin with "you might try this..." or "I think this might work, but YMMV..." How do these wind up being the top ranked results by google? Who embeds links to that stuff? My experience with Windows is, like yours, the opposite. The top ranked result will be correct and to the point. No weasel wording.

Those results are often in big forums like ubuntuforums.org that get a lot of links etc, so even if one thread doesn't have many incoming links, it may still get a top ranking. Also my blog entries (hosted at wordpress.com) get on the google frontpage when looking for the specific topic, even though my blog is mostly unknown, has 2-20 visitors per day and almost no incoming links.. Googles algorithms often do seem like voodoo ;) Also: Many problems (and their correct solutions) heavily depend on your system. What desktop environment is used, what additional stuff (dbus, hal, ...) is used, what are the versions of this stuff (and X.org), what distribution is used, ... There may be different default configurations shipped depending on what distribution (and what version of that distribution) you use, ... So there often is no single correct answer that will work for anyone. Still, in my experience those HOWTOs often work (it may help to look at multiple HOWTOs and compare them if you're not sure, if it applies to your system) or at least push you in the right direction. Cheers, - Daniel
Jan 11 2011
next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Andrej Mitrovic Wrote:

 Google does seem to take into account whatever information it has on
 you, which might explain why your own blog is a top result for you.
 
 If I log out of Google and delete my preferences, searching for "D"
 won't find anything about the D language in the top results. But if I
 log in and search "D" again, the D website will be the top result.

Best place to go for ranking information on your website: https://www.google.com/webmasters/tools/home?hl=en&pli=1 Need to show you own the site though.
Jan 11 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:igijc7$27pv$4 digitalmars.com...
 Am 11.01.2011 22:36, schrieb Walter Bright:
 Andrej Mitrovic wrote:
 That's my biggest problem with Linux. Having technical problems is not
 the issue, finding the right solution in the sea of forum posts is the
 problem.

The worst ones begin with "you might try this..." or "I think this might work, but YMMV..." How do these wind up being the top ranked results by google? Who embeds links to that stuff? My experience with Windows is, like yours, the opposite. The top ranked result will be correct and to the point. No weasel wording.

Those results are often in big forums like ubuntuforums.org that get a lot of links etc, so even if one thread doesn't have many incoming links, it may still get a top ranking. Also my blog entries (hosted at wordpress.com) get on the google frontpage when looking for the specific topic, even though my blog is mostly unknown, has 2-20 visitors per day and almost no incoming links.. Googles algorithms often do seem like voodoo ;) Also: Many problems (and their correct solutions) heavily depend on your system. What desktop environment is used, what additional stuff (dbus, hal, ...) is used, what are the versions of this stuff (and X.org), what distribution is used, ... There may be different default configurations shipped depending on what distribution (and what version of that distribution) you use, ... So there often is no single correct answer that will work for anyone. Still, in my experience those HOWTOs often work (it may help to look at multiple HOWTOs and compare them if you're not sure, if it applies to your system) or at least push you in the right direction.

That's probably one of the biggest things that's always bothered me about linux (not that there aren't plenty of other things that bother me about every other OS in existence). For something that's considered so standards-compliant/standards-friendly (compared to, say MS), it's painfully *un*standardized.
Jan 11 2011
prev sibling parent Christopher Nicholson-Sauls <ibisbasenji gmail.com> writes:
On 01/11/11 15:36, Walter Bright wrote:
 Andrej Mitrovic wrote:
 That's my biggest problem with Linux. Having technical problems is not
 the issue, finding the right solution in the sea of forum posts is the
 problem.

The worst ones begin with "you might try this..." or "I think this might work, but YMMV..." How do these wind up being the top ranked results by google? Who embeds links to that stuff?

Nobody. The first "secret" of Linux tech-help is that most real help is dished out via IRC channels. One just has to visit their distro of choice's website and there will inevitably be a listing for an IRC channel or two -- often with one specifically for new users. It may sound like a lot of trouble, but getting help from the source and live is worlds above scanning forum posts hoping the people posting know more than you do. And thanks to the global scale of most FOSS communities, there's always someone around -- and it didn't cost you a dime. That said, a little more integrity in the forums that do exist would be nice. LinuxQuestions.org seems to be one of the better ones, from what I've seen of it. -- Chris N-S
Jan 12 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Vladimir Panteleev wrote:
 On Sun, 09 Jan 2011 00:34:19 +0200, Walter Bright 
 <newshound2 digitalmars.com> wrote:
 
 Yeah, I could spend an afternoon doing that.

sudo apt-get build-dep meld wget http://ftp.gnome.org/pub/gnome/sources/meld/1.5/meld-1.5.0.tar.bz2 tar jxf meld-1.5.0.tar.bz2 cd meld-1.5.0 make sudo make install You're welcome ;) (Yes, I just tested it on a Ubuntu install, albeit 10.10. No, no ./configure needed. For anyone else who tries this and didn't already have meld, you may need to apt-get install python-gtk2 manually.)

It doesn't work: walter mercury:~$ ./buildmeld [sudo] password for walter: Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to find a source package for meld --2011-01-18 21:35:07-- http://ftp.gnome.org/pub/gnome/sources/meld/1.5/meld-1.5.0.tar.bz2%0D Resolving ftp.gnome.org... 130.239.18.163, 130.239.18.173 Connecting to ftp.gnome.org|130.239.18.163|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2011-01-18 21:35:08 ERROR 404: Not Found. tar: meld-1.5.0.tar.bz2\r: Cannot open: No such file or directory tar: Error is not recoverable: exiting now tar: Child returned status 2 tar: Error exit delayed from previous errors : No such file or directoryld-1.5.0 : command not found: make '. Stop. No rule to make target `install
Jan 18 2011
parent reply KennyTM~ <kennytm gmail.com> writes:
On Jan 19, 11 13:38, Walter Bright wrote:
 Vladimir Panteleev wrote:
 On Sun, 09 Jan 2011 00:34:19 +0200, Walter Bright
 <newshound2 digitalmars.com> wrote:

 Yeah, I could spend an afternoon doing that.

sudo apt-get build-dep meld wget http://ftp.gnome.org/pub/gnome/sources/meld/1.5/meld-1.5.0.tar.bz2 tar jxf meld-1.5.0.tar.bz2 cd meld-1.5.0 make sudo make install You're welcome ;) (Yes, I just tested it on a Ubuntu install, albeit 10.10. No, no ./configure needed. For anyone else who tries this and didn't already have meld, you may need to apt-get install python-gtk2 manually.)

It doesn't work: walter mercury:~$ ./buildmeld [sudo] password for walter: Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to find a source package for meld --2011-01-18 21:35:07-- http://ftp.gnome.org/pub/gnome/sources/meld/1.5/meld-1.5.0.tar.bz2%0D Resolving ftp.gnome.org... 130.239.18.163, 130.239.18.173 Connecting to ftp.gnome.org|130.239.18.163|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2011-01-18 21:35:08 ERROR 404: Not Found. tar: meld-1.5.0.tar.bz2\r: Cannot open: No such file or directory tar: Error is not recoverable: exiting now tar: Child returned status 2 tar: Error exit delayed from previous errors : No such file or directoryld-1.5.0 : command not found: make '. Stop. No rule to make target `install

You should use LF ending, not CRLF ending.
Jan 18 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
KennyTM~ wrote:
 You should use LF ending, not CRLF ending.

I never thought of that. Fixing that, it gets further, but still innumerable errors: walter mercury:~$ ./buildmeld [sudo] password for walter: Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: autoconf automake1.7 autotools-dev cdbs debhelper fdupes gettext gnome-pkg-tools html2text intltool intltool-debian libmail-sendmail-perl libsys-hostname-long-perl m4 po-debconf python-dev python2.5-dev 0 upgraded, 17 newly installed, 0 to remove and 0 not upgraded. Need to get 7387kB of archives. After this operation, 23.9MB of additional disk space will be used. Do you want to continue [Y/n]? Y WARNING: The following packages cannot be authenticated! m4 autoconf autotools-dev automake1.7 html2text gettext intltool-debian po-debconf debhelper fdupes intltool cdbs gnome-pkg-tools libsys-hostname-long-perl libmail-sendmail-perl python2.5-dev python-dev Install these packages without verification [y/N]? y Get:1 http://ca.archive.ubuntu.com intrepid/main m4 1.4.11-1 [263kB] Err http://ca.archive.ubuntu.com intrepid/main autoconf 2.61-7ubuntu1 404 Not Found [IP: 91.189.92.170 80] Err http://ca.archive.ubuntu.com intrepid/main autotools-dev 20080123.1 404 Not Found [IP: 91.189.92.170 80] Get:2 http://ca.archive.ubuntu.com intrepid/main automake1.7 1.7.9-9 [391kB] Get:3 http://ca.archive.ubuntu.com intrepid/main html2text 1.3.2a-5 [95.6kB] Err http://ca.archive.ubuntu.com intrepid/main gettext 0.17-3ubuntu2 404 Not Found [IP: 91.189.92.170 80] Get:4 http://ca.archive.ubuntu.com intrepid/main intltool-debian 0.35.0+20060710.1 [31.6kB] Get:5 http://ca.archive.ubuntu.com intrepid/main po-debconf 1.0.15ubuntu1 [237kB] Err http://ca.archive.ubuntu.com intrepid/main debhelper 7.0.13ubuntu1 404 Not Found [IP: 91.189.92.170 80] Get:6 http://ca.archive.ubuntu.com intrepid/main fdupes 1.50-PR2-1 [19.1kB] Err http://ca.archive.ubuntu.com intrepid/main intltool 0.40.5-0ubuntu1 404 Not Found [IP: 91.189.92.170 80] Err http://ca.archive.ubuntu.com intrepid/main cdbs 0.4.52ubuntu7 404 Not Found [IP: 91.189.92.170 80] Err http://ca.archive.ubuntu.com intrepid/main gnome-pkg-tools 0.13.6ubuntu1 404 Not Found [IP: 91.189.92.170 80] Get:7 http://ca.archive.ubuntu.com intrepid/main libsys-hostname-long-perl 1.4-2 [11.4kB] Err http://ca.archive.ubuntu.com intrepid/main libmail-sendmail-perl 0.79-5 404 Not Found [IP: 91.189.92.170 80] Err http://ca.archive.ubuntu.com intrepid-updates/main python2.5-dev 2.5.2-11.1ubuntu1.1 404 Not Found [IP: 91.189.92.170 80] Err http://ca.archive.ubuntu.com intrepid/main python-dev 2.5.2-1ubuntu1 404 Not Found [IP: 91.189.92.170 80] Err http://security.ubuntu.com intrepid-security/main python2.5-dev 2.5.2-11.1ubuntu1.1 404 Not Found [IP: 91.189.92.167 80] Fetched 1050kB in 2s (403kB/s) Failed to fetch http://ca.archive.ubuntu.com/ubuntu/pool/main/a/autoconf/autoconf_2 61-7ubuntu1_all.deb 404 Not Found [IP: 91.189.92.170 80] Failed to fetch http://ca.archive.ubuntu.com/ubuntu/pool/main/a/autotools-dev/autotools-de _20080123.1_all.deb 404 Not Found [IP: 91.189.92.170 80] Failed to fetch http://ca.archive.ubuntu.com/ubuntu/pool/main/g/gettext/gettext_0.1 -3ubuntu2_amd64.deb 404 Not Found [IP: 91.189.92.170 80] Failed to fetch http://ca.archive.ubuntu.com/ubuntu/pool/main/d/debhelper/debhelper_7 0.13ubuntu1_all.deb 404 Not Found [IP: 91.189.92.170 80] Failed to fetch http://ca.archive.ubuntu.com/ubuntu/pool/main/i/intltool/intltool_0.4 .5-0ubuntu1_all.deb 404 Not Found [IP: 91.189.92.170 80] Failed to fetch http://ca.archive.ubuntu.com/ubuntu/pool/main/c/cdbs/cdbs_0.4.52ubuntu7_all.deb 404 Not Found [IP: 91.189.92.170 80] Failed to fetch http://ca.archive.ubuntu.com/ubuntu/pool/main/g/gnome-pkg-tools/gnome-pkg-tools_0 13.6ubuntu1_all.deb 404 Not Found [IP: 91.189.92.170 80] Failed to fetch http://ca.archive.ubuntu.com/ubuntu/pool/main/libm/libmail-sendmail-perl/libmail-sendmail perl_0.79-5_all.deb 404 Not Found [IP: 91.189.92.170 80] Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/p/python2.5/python2.5-dev_2.5.2-11. ubuntu1.1_amd64.deb 404 Not Found [IP: 91.189.92.167 80] Failed to fetch http://ca.archive.ubuntu.com/ubuntu/pool/main/p/python-defaults/python-dev_2. .2-1ubuntu1_all.deb 404 Not Found [IP: 91.189.92.170 80] E: Unable to fetch some archives, try running apt-get update or apt-get --fix-missing. E: Failed to process build dependencies --2011-01-19 03:07:16-- http://ftp.gnome.org/pub/gnome/sources/meld/1.5/meld-1.5.0.tar.bz2 Resolving ftp.gnome.org... 130.239.18.163, 130.239.18.173 Connecting to ftp.gnome.org|130.239.18.163|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 330845 (323K) [application/x-bzip2] Saving to: `meld-1.5.0.tar.bz2' 100%[=============================================================>] 330,845 179K/s in 1.8s 2011-01-19 03:07:19 (179 KB/s) - `meld-1.5.0.tar.bz2' saved [330845/330845] python tools/install_paths \ libdir=/usr/local/lib/meld \ localedir=/usr/local/share/locale \ helpdir=/usr/local/share/gnome/help/meld \ sharedir=/usr/local/share/meld \ < bin/meld > bin/meld.install python tools/install_paths \ libdir=/usr/local/lib/meld \ localedir=/usr/local/share/locale \ helpdir=/usr/local/share/gnome/help/meld \ sharedir=/usr/local/share/meld \ < meld/paths.py > meld/paths.py.install intltool-merge -d po data/meld.desktop.in data/meld.desktop make: intltool-merge: Command not found make: *** [meld.desktop] Error 127 intltool-merge -d po data/meld.desktop.in data/meld.desktop make: intltool-merge: Command not found make: *** [meld.desktop] Error 127 walter mercury:~$
Jan 19 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Vladimir Panteleev wrote:
 On Wed, 19 Jan 2011 13:11:07 +0200, Walter Bright 
 <newshound2 digitalmars.com> wrote:
 
 KennyTM~ wrote:
 You should use LF ending, not CRLF ending.

I never thought of that. Fixing that, it gets further, but still innumerable errors:

If apt-get update doesn't fix it, only an update will - looks like your Ubuntu version is so old, Canonical is no longer maintaining repositories for it. The only alternative is downloading and installing the components manually, and that probably will take half a day :P

Yeah, I figured that. Thanks for the try, anyway!
Jan 19 2011
prev sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 01/19/2011 04:18 PM, Gour wrote:
 That's why we wrote it would be better to use some rolling release
 like Archlinux where distro cannot become so outdated that it's not
 possible to upgrade easily.

https://wiki.archlinux.org/index.php/FAQ : "Q) Why would I not want to use Arch? A) [...] you do not have the ability/time/desire for a 'do-ityourself' GNU/Linux distribution" I also don't see how Archlinux protects you from an outdated system. It's up to you to update your system. The longer you wait, the more chance incompatibilities creep in. However, the tradeoff is that if you update weekly or monthly, then you will spend more time encountering problems between upgrades. There's no silver bullet here. Personally, I think you should just suck it up, make a backup of your system (which you should be doing routinely anyways), and upgrade once a year. The worst case scenario is that you re-install from scratch. It's probably better to do that once in a while anyways, as cruft tends to accumulate when upgrading in place.
Jan 19 2011
next sibling parent Gary Whatmore <no spam.sp> writes:
Jeff Nowakowski Wrote:

 On 01/19/2011 04:18 PM, Gour wrote:
 That's why we wrote it would be better to use some rolling release
 like Archlinux where distro cannot become so outdated that it's not
 possible to upgrade easily.

https://wiki.archlinux.org/index.php/FAQ : "Q) Why would I not want to use Arch? A) [...] you do not have the ability/time/desire for a 'do-ityourself' GNU/Linux distribution"

This is something the Gentoo and Arch fanboys don't get. They don't have any idea how little time a typical Ubuntu user spends maintaining the system and installing updates. The best solution is to hire some familiar with computers (e.g. nephew with chocolate). It's almost free and they will want to spend hours configuring your system. This way you spend none of your own time maintaining. Another option is to turn on all automatic updates. Everything happens in the background. It might ask for a sudo password once in a week. In any case the Ubuntu user spends less than 10 minutes per month maintaining the system. It's possible but you need compatible hardware (Nvidia graphics and Wifi without a proprietary firmware, at least). You can't beat that.
 I also don't see how Archlinux protects you from an outdated system. 
 It's up to you to update your system. The longer you wait, the more 
 chance incompatibilities creep in.

I personally use CentOS for anything stable. I *Was* a huge Gentoo fanboy, but the compilation simply takes too much time, and something is constantly broken if you enable ~x86 packages. I've also tried Arch. All the cool kids use it, BUT it doesn't automatically handle any configuration files in /etc and even worse, if you enable the "unstable" community repositories, the packages won't stay there long in the repository - a few days! The replacement policy is nuts. One of the packages was already removed from the server before pacman (the package manager) started downloading it! Arch is a pure community based distro for hardcore enthusiastics. It's fundamentally incompatible with stability.
 
 However, the tradeoff is that if you update weekly or monthly, then you 
 will spend more time encountering problems between upgrades. There's no 
 silver bullet here.

Yes. Although I fail to see why upgrating Ubuntu is so hard. It only takes one hour or two every 6 months or every 3 years. The daily security updates should work automatically just like in Windows.
 
 Personally, I think you should just suck it up, make a backup of your 
 system (which you should be doing routinely anyways), and upgrade once a 
 year.

Dissing Walter has become a sad tradition here. I'm sure a long time software professional knows how to make backups and he has likely written his own backup software and RAID drivers before you were even born. The reason Waltzy feels so clumsy in Linux world is probably the Windows XP attitude we all long time Windows users suffer from. Many powerusers are still using Windows XP, and it has a long term support plan. The support might last forever. You've updated Windows XP only three times. Probably 20 versions of Ubuntu have appeared since Windows XP was launched. Ubuntu is stuck with the "we MUST release SOMETHING at least every 3 years" just like WIndows did before XP: Win 3.11 -> 95 -> 98 -> XP (all intervals exactly 3 years).
Jan 19 2011
prev sibling next sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 01/20/2011 12:24 AM, Gour wrote:
 I've feeling that you just copied the above from FAQ and never
 actually tried Archlinux.

No, I haven't tried it. I'm not going to try every OS that comes down the pike. If the FAQ says that you're going to have to be more of an expert with your system, then I believe it. If it's wrong, then maybe you can push them to update it.
 The "do-it-yourself" from the above means that in Arch user is not
 forced to use specific DE, WM etc., can choose whether he prefers WiCD
 over NM etc.

So instead of giving you a bunch of sane defaults, you have to make a bunch of choices up front. That's a heavy investment of time, especially for somebody unfamiliar with Linux.
 That's not true...In Arch there is simply no Arch-8.10 or Arch-10.10
 which means that whenever you update your system package manager will
 simply pull all the packages which are required for desired kernel,
 gcc version etc.

The upgrade problems are still there. *Every package* you upgrade has a chance to be incompatible with the previous version. The longer you wait, the more incompatibilities there will be.
 Otoh, with Ubuntu, upgrade from 8.10 to 10.10 is always a major
 undertaking (I'm familiar with it since  '99 when I used SuSE and had
 experience with deps hell.)

Highlighting the problem of waiting too long to upgrade. You're skipping an entire release. I'd like to see you take a snapshot of Arch from 2008, use the system for 2 years without updating, and then upgrade to the latest packages. Do you think Arch is going to magically have no problems?
Jan 20 2011
parent Jeff Nowakowski <jeff dilacero.org> writes:
On 01/20/2011 07:33 AM, Gour wrote:
 On Thu, 20 Jan 2011 06:39:08 -0500
 Jeff Nowakowski<jeff dilacero.org>  wrote:


 No, I haven't tried it. I'm not going to try every OS that comes down
 the pike.

Then please, without any offense, do not give advises about something which you did not try. I did use Ubuntu...

Please yourself. I quoted from the FAQ from the distribution's main site. If that's wrong, then Arch has a big public relations problem. I can make rational arguments without having used a system.
 That's a heavy investment of time, especially for somebody
 unfamiliar with Linux.

Again, you're speaking without personal experience...

From Jonathan M Davis in this thread: "There is no question that Arch takes more to manage than a number of other distros. [..] Arch really doesn't take all that much to maintain, but it does have a higher setup cost than your average distro, and you do have to do some level of manual configuration that I'd expect a more typical distro like OpenSuSE or Ubuntu to take care of for you."
 Moreover, in TDPL's foreword, Walter speaks about himself as "..of an
 engineer..", so I'm sure he is capable to handle The Arch Way

You're talking about somebody who is running a nearly 3 year old version of Ubuntu because he had one bad upgrade experience, and is probably running software full of security holes. If he can't spend a day a year to upgrade his OS, what makes you think he wants to spend time on a more demanding distro?
 There are no incompatibilities...if I upgrade kernel, it means that
 package manager will figure out what components has to be updated...

And what happens when the kernel, as it often does, changes the way it handles things like devices, and expects the administrator to do some tweaking to handle the upgrade? What happens when you upgrade X and it no longer supports your video chipset? What happens when you upgrade something as basic as the DNS library, and it reacts badly with your router? Is Arch going to maintain your config files for you? Is it going to handle jumping 2 or 3 versions for software that can only upgrade from one version ago? These are real world examples. Arch is not some magic distribution that will make upgrade problems go away.
 Remember: there are no packages 'tagged' for any specific release!

Yeah, I know. I also run Debian Testing, which is a "rolling release". I'm not some Ubuntu noob.
Jan 20 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Gour wrote:
 Otoh, with Ubuntu, upgrade from 8.10 to 10.10 is always a major
 undertaking (I'm familiar with it since  '99 when I used SuSE and had
 experience with deps hell.)

I finally did do it, but as a clean install. I found an old 160G drive, wiped it, and installed 10.10 on it. (Amusingly, the "About Ubuntu" box says it's version 11.04, and /etc/issue says it's 10.10.) I attached the old drive through a usb port, and copied everything on it into a subdirectory of the new drive. Then, file and directory by file and directory, I moved the files into place on my new home directory. The main difficulty was the . files, which litter the home directory and gawd knows what they do or are for. This is one reason why I tend to stick with all defaults. The only real problem I've run into (so far) is the sunbird calendar has been unceremoniously dumped from Ubuntu. The data file for it is in some crappy binary format, so poof, there goes all my calendar data. Why do I bother with this crap. I think I'll stick with the ipod calendar. Phobos1 on 10.10 is dying in its unit tests because Ubuntu changed how gcc's strtof() works. Erratic floating point is typical of C runtime library implementations (the transcendentals are often sloppily done), which is why more and more Phobos uses its own implementations that Don has put together.
Jan 21 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/22/11 12:35 AM, Walter Bright wrote:
 Phobos1 on 10.10 is dying in its unit tests because Ubuntu changed how
 gcc's strtof() works. Erratic floating point is typical of C runtime
 library implementations (the transcendentals are often sloppily done),
 which is why more and more Phobos uses its own implementations that Don
 has put together.

I think we must change to our own routines anyway. One strategic advantage of native implementations of strtof (and the converse sprintf etc.) is that we can CTFE them, which opens the door to interesting applications. I have something CTFEable starting from your dmc code, but never got around to handling all of the small details. Andrei
Jan 21 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 On 1/22/11 12:35 AM, Walter Bright wrote:
 Phobos1 on 10.10 is dying in its unit tests because Ubuntu changed how
 gcc's strtof() works. Erratic floating point is typical of C runtime
 library implementations (the transcendentals are often sloppily done),
 which is why more and more Phobos uses its own implementations that Don
 has put together.

I think we must change to our own routines anyway. One strategic advantage of native implementations of strtof (and the converse sprintf etc.) is that we can CTFE them, which opens the door to interesting applications.

We can also make our own conversion routines consistent, pure, thread safe and locale-independent.
Jan 22 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Gour wrote:
 I'm very seriously considering to put PC-BSD on my desktop and of
 several others in order to reduce my admin-time required to maint. all
 those machines.

OSX is the only OS (besides DOS) I've had that had painless upgrades. Windows upgrades never ever work in place (at least not for me). You have to wipe the disk, install from scratch, then reinstall all your apps and reconfigure them. You're hosed if you lose an install disk or the serial # for it. Ubuntu isn't much better, but at least you don't have to worry about install disks and serial numbers. I just keep a list of sudo apt-get commands! That works pretty good until the Ubuntu gods just decide to drop kick your apps (like sunbird) out of the repository.
Jan 22 2011
next sibling parent reply Christopher Nicholson-Sauls <ibisbasenji gmail.com> writes:
On 01/22/11 03:57, spir wrote:
 On 01/22/2011 09:58 AM, Walter Bright wrote:
 Gour wrote:
 I'm very seriously considering to put PC-BSD on my desktop and of
 several others in order to reduce my admin-time required to maint. all
 those machines.

OSX is the only OS (besides DOS) I've had that had painless upgrades. Windows upgrades never ever work in place (at least not for me). You have to wipe the disk, install from scratch, then reinstall all your apps and reconfigure them.

Same in my experience. I had to recently re-install from scratch my ubuntu box recently (recently why I have the same amusing info as Walter telling my machine runs ubuntu 11.04?) because 10.04 --> 10.10 upgrade miserably crashed (at the end of the procedure, indeed). And no, this is not due to me naughtily the system; instead while userland is highly personalised I do not touch the rest (mainly my brain cannot cope with the standard unix filesystem hierarchy). (I use linux only for philosophical reasons, else would happily switch to mac.) Denis _________________ vita es estrany spir.wikidot.com

Likewise I had occasional issues with Ubuntu/Kubuntu upgrades when I was using it. Moving to a "rolling release" style distribution (Gentoo) changed everything for me. I haven't had a single major issue since. (I put "major" in there because there have been issues, but of the "glance at the screen, notice the blocker, type out the one very short command that will fix it, continue updating" variety.) Heck, updating has proven so straight-forward that I check for updates almost daily. I originally went to Linux for "philosophical" reasons, as well, but now that I've had a taste of a "real distro" I really don't have any interest in toying around with anything else. I do have a Windows install for development/testing purposes though... running in a VM. ;) Amazingly enough, Windows seems to be perfectly happy running as a guest O/S. If it was possible to do the same with OS X, I would. (Anyone know a little trick for that, using VirtualBox?) -- Chris N-S
Jan 22 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 22.01.2011 17:36, schrieb Andrej Mitrovic:
 On 1/22/11, Christopher Nicholson-Sauls<ibisbasenji gmail.com>  wrote:
   If it was possible to do the same with OS
 X, I would.  (Anyone know a little trick for that, using VirtualBox?)

No, that is illegal! But you might want to do a google search for *cough* iDeneb *cough* and download vmware player. :p

A google search for virtualbox osx takwing may be interesting as well.
Jan 22 2011
prev sibling next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 22.01.2011 13:21, schrieb retard:
 Sat, 22 Jan 2011 00:58:59 -0800, Walter Bright wrote:

 Gour wrote:
 I'm very seriously considering to put PC-BSD on my desktop and of
 several others in order to reduce my admin-time required to maint. all
 those machines.

OSX is the only OS (besides DOS) I've had that had painless upgrades. Windows upgrades never ever work in place (at least not for me). You have to wipe the disk, install from scratch, then reinstall all your apps and reconfigure them. You're hosed if you lose an install disk or the serial # for it. Ubuntu isn't much better, but at least you don't have to worry about install disks and serial numbers. I just keep a list of sudo apt-get commands! That works pretty good until the Ubuntu gods just decide to drop kick your apps (like sunbird) out of the repository.

Don't blame Ubuntu, http://en.wikipedia.org/wiki/Mozilla_Sunbird "It was developed as a standalone version of the Lightning calendar and scheduling extension for Mozilla Thunderbird. Development of Sunbird was ended with release 1.0 beta 1 to focus on development of Mozilla Lightning.[6][7]" Ubuntu doesn't drop support for widely used software. I'd use Google's Calendar instead.

Ubuntu doesn't include Lightning, either. Walter: You could add the lightning plugin to your thunderbird from the mozilla page: http://www.mozilla.org/projects/calendar/lightning/index.html Hopefully it automatically imports your sunbird data or is at least able to import it manually.
Jan 22 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
 Ubuntu doesn't drop support for widely used software. I'd use Google's 
 Calendar instead.

I'm really not interested in Google owning my private data.
Jan 22 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/22/11 3:03 PM, Walter Bright wrote:
 retard wrote:
 Ubuntu doesn't drop support for widely used software. I'd use Google's
 Calendar instead.

I'm really not interested in Google owning my private data.

Google takes email privacy very seriously. Only last week they fired an employee for snooping through someone else's email. http://techcrunch.com/2010/09/14/google-engineer-spying-fired/ Of course, that could be framed either as a success or a failure of Google's privacy enforcement. Several companies are using gmail for their email infrastructure. Andrei
Jan 22 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Google takes email privacy very seriously. Only last week they fired an 
 employee for snooping through someone else's email.
 
 http://techcrunch.com/2010/09/14/google-engineer-spying-fired/

That's good to know. On the other hand, Google keeps information forever. Ownership, management, policies, and practices change. And to be frank, the fact that some of Google's employees are not authorized to look at emails means that others are. And those others are subject to the usual human weaknesses of bribery, blackmail, temptation, voyeurism, etc. Heck, the White House is famous for being a leaky organization, despite extensive security. I rent storage on Amazon's servers, but the stuff I send there is encrypted before Amazon ever sees it. I don't have to depend at all on Amazon having a privacy policy or airtight security. Google could implement their Calendar, etc., stuff the same way. I'd even pay for it (like I pay Amazon).
Jan 22 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/22/2011 09:58 AM, Walter Bright wrote:
 Gour wrote:
 I'm very seriously considering to put PC-BSD on my desktop and of
 several others in order to reduce my admin-time required to maint. all
 those machines.

OSX is the only OS (besides DOS) I've had that had painless upgrades. Windows upgrades never ever work in place (at least not for me). You have to wipe the disk, install from scratch, then reinstall all your apps and reconfigure them.

Same in my experience. I had to recently re-install from scratch my ubuntu box recently (recently why I have the same amusing info as Walter telling my machine runs ubuntu 11.04?) because 10.04 --> 10.10 upgrade miserably crashed (at the end of the procedure, indeed). And no, this is not due to me naughtily the system; instead while userland is highly personalised I do not touch the rest (mainly my brain cannot cope with the standard unix filesystem hierarchy). (I use linux only for philosophical reasons, else would happily switch to mac.) Denis _________________ vita es estrany spir.wikidot.com
Jan 22 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Vladimir Panteleev wrote:
 http://brizoma.wordpress.com/2010/05/04/sunbird-and-lightning-removed-from-ubun
u-10-04-lucid-lynx/ 

Thanks for finding that. But I think I'll stick for now with the ipod's calendar. It's more useful anyway, as it moves with me.
Jan 22 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 22.01.2011 22:31, schrieb retard:
 Sat, 22 Jan 2011 13:12:26 -0800, Walter Bright wrote:

 Vladimir Panteleev wrote:
 http://brizoma.wordpress.com/2010/05/04/sunbird-and-lightning-removed-


 Thanks for finding that. But I think I'll stick for now with the ipod's
 calendar. It's more useful anyway, as it moves with me.

Does the new Ubuntu overall work better than the old one? Would be amazing if the media players are still all broken.

And is the support for the graphics chip better, i.e. can you use full resolution?
Jan 22 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
Daniel Gibson wrote:
 And is the support for the graphics chip better, i.e. can you use full 
 resolution?

Yes, it recognized my resolution automatically. That's a nice improvement.
Jan 22 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
 Does the new Ubuntu overall work better than the old one? Would be 
 amazing if the media players are still all broken.

I haven't tried the sound yet, but the video playback definitely is better. Though the whole screen flashes now and then, like the video mode is being reset badly. This is new behavior.
Jan 22 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 01/22/2011 07:35 AM, Walter Bright wrote:
 I finally did do it, but as a clean install. I found an old 160G drive,
 wiped it, and installed 10.10 on it. (Amusingly, the "About Ubuntu" box
 says it's version 11.04, and /etc/issue says it's 10.10.)

Same for me ;-) _________________ vita es estrany spir.wikidot.com
Jan 22 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 08 January 2011 14:34:19 Walter Bright wrote:
 Michel Fortin wrote:
 I know you had your reasons, but perhaps it's time for you upgrade to a
 more recent version of Ubuntu? That version is what comes with Hardy
 Heron (april 2008).
 <https://launchpad.net/ubuntu/+source/meld>

I know. The last time I upgraded Ubuntu in place it f****d up my system so bad I had to wipe the disk and start all over. It still won't play videos correctly (the previous Ubuntu worked fine), the rhythmbox music player never worked again, it wiped out all my virtual boxes, I had to spend hours googling around trying to figure out how to reconfigure the display driver so the monitor worked again, etc. I learned my lesson! Yes, I'll eventually upgrade, but I'm not looking forward to it.

A while back I took to putting /home on a separate partition from the root directory, and I never upgrade in place. I replace the whole thing every time. Maybe it's because I've never trusted Windows to do it correctly, but I've never thought that it was a good idea to upgrade in place. I never do it on any OS. And by having /home on its own partition, it doesn't affect my data. Sometimes, config files can be an issue, but worse case, that's fixed by blowing them away. Of course, I use neither Ubuntu nor Gnome, so I don't know what the exact caveats are with those. And at the moment, I'm primarily using Arch, which has rolling releases, so unless I screw up my machine, I pretty much don't have to worry about updating the OS to a new release. The pieces get updated as you go, and it works just fine (unlike Gentoo, where you can be screwed on updates because a particular package didn't build). Of course, I'd have got nuts having an installation as old as yours appears to be, so we're obviously of very different mindsets when dealing with upgrades. Still, I'd advise making /home its own partition and then doing clean installs of the OS whenever you upgrade. - Jonathan M Davis
Jan 08 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 2011-01-08 at 18:22 -0800, Jonathan M Davis wrote:
 On Saturday 08 January 2011 14:34:19 Walter Bright wrote:
 Michel Fortin wrote:
 I know you had your reasons, but perhaps it's time for you upgrade to=



 more recent version of Ubuntu? That version is what comes with Hardy
 Heron (april 2008).
 <https://launchpad.net/ubuntu/+source/meld>

I know. The last time I upgraded Ubuntu in place it f****d up my system=


 bad I had to wipe the disk and start all over. It still won't play vide=


 correctly (the previous Ubuntu worked fine), the rhythmbox music player
 never worked again, it wiped out all my virtual boxes, I had to spend
 hours googling around trying to figure out how to reconfigure the displ=


 driver so the monitor worked again, etc.


Personally I have never had an in-place Ubuntu upgrade f*** up any of my machines -- server, workstation, laptops. However, I really feel your pain about video and audio tools on Ubuntu, these have regularly been screwed over by an upgrade. There are also other niggles: my current beef is that the 10.10 upgrade stopped my Lenovo T500 from going to sleep when closing the lid. On my laptops I have two system partitions so as to dual boot between Debian Testing and the latest released Ubuntu. This way I find I always have a reasonably up to date system that works as I want it. Currently I am having a Debian Testing period pending 11.04 being released.
 I learned my lesson! Yes, I'll eventually upgrade, but I'm not looking
 forward to it.

A while back I took to putting /home on a separate partition from the roo=

 directory, and I never upgrade in place. I replace the whole thing every =

 Maybe it's because I've never trusted Windows to do it correctly, but I'v=

 thought that it was a good idea to upgrade in place. I never do it on any=

 And by having /home on its own partition, it doesn't affect my data. Some=

 config files can be an issue, but worse case, that's fixed by blowing the=

 course, I use neither Ubuntu nor Gnome, so I don't know what the exact ca=

 are with those. And at the moment, I'm primarily using Arch, which has ro=

 releases, so unless I screw up my machine, I pretty much don't have to wo=

 about updating the OS to a new release. The pieces get updated as you go,=

 works just fine (unlike Gentoo, where you can be screwed on updates becau=

 particular package didn't build).

I always have /home as a separate partition as I dual boot between Debian and Ubuntu from two distinct / partitions. But I always upgrade in place -- but having the dual boot makes for trivially easy recovery from problems. Debian Testing is really a rolling release but it tends to be behind Ubuntu is some versions of things and ahead in others. Also Ubuntu has non-free stuff that is forbidden on Debian. Not to mention the F$$$F$$ fiasco! =20
 Of course, I'd have got nuts having an installation as old as yours appea=

 be, so we're obviously of very different mindsets when dealing with upgra=

 Still, I'd advise making /home its own partition and then doing clean ins=

 of the OS whenever you upgrade.

I have to agree about being two years behind, this is too far to be comfortable. I would definitely recommend an upgrade to Walter's machines --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 09 2011
prev sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sun, 09 Jan 2011 21:02:13 +0200, Daniel Gibson <metalcaedes gmail.com>  
wrote:

 What's F$$$F$$?

FireFox/IceWeasel: http://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 09 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
 One thing came to my mind. Unless you're using Ubuntu 8.04 LTS,

I'm using 8.10, and I've noticed that no more updates are coming.
 your 
 Ubuntu version isn't supported anymore. They might have already removed 
 the package repositories for unsupported versions and that might indeed 
 lead to problems with graphics and video players as you said.

What annoyed the heck out of me was the earlier (7.xx) version of Ubuntu *did* work.
 The support for desktop 8.04 and 9.10 is also nearing its end (April this 
 year). I'd recommend backing up your /home and installing 10.04 LTS or 
 10.10 instead.

Yeah, I know I'll be forced to upgrade soon. One thing that'll make it easier is I abandoned using Ubuntu for multimedia. For example, to play Pandora I now just plug my ipod into my stereo <g>. I just stopped using youtube on Ubuntu, as I got tired of the video randomly going black, freezing, etc.
Jan 11 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-01-06 21:12, Michel Fortin wrote:
 On 2011-01-06 15:01:18 -0500, Jesse Phillips
 <jessekphillips+D gmail.com> said:

 Walter Bright Wrote:

 A couple months back, I did propose moving to git on the dmd
 internals mailing
 list, and nobody was interested.


I probably wasn't on the list at the time. I'm certainly interested, it'd certainly make it easier for me, as I'm using git locally to access that repo.
 One thing I like a lot about svn is this:

 http://www.dsource.org/projects/dmd/changeset/291

You mean this: https://github.com/braddr/dmd/commit/f1fde96227394f926da5841db4f0f4c608b2e7b2

That's

comes with a web interface that looks like this (pointing to a specific diff): <http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git/commitdiff/d7214dcb5be988a5c7d407f907c7e7e789872d24> Also when I want an overview with git I just type gitk on the command line to bring a window where I can browser the graph of forks, merges and commits and see the diff for each commit. Here's what gitk looks like: <http://michael-prokop.at/blog/img/gitk.png>

Have you heard of gitx? I suggest you take a look at it: http://gitx.frim.nl/index.html . It's a Mac OS X GUI for git.
 where the web view will highlight the revision's changes. Does git or
 mercurial
 do that? The other thing I like a lot about gif is it sends out
 emails for each
 checkin.

 One thing I would dearly like is to be able to merge branches using
 meld.

 http://meld.sourceforge.net/

Git does not have its own merge tool. You are free to use meld. Though there is gitmerge which can run meld as the merge tool.

Looks like meld itself used git as it's repository. I'd be surprised if it doesn't work with git. :-)

-- /Jacob Carlborg
Jan 08 2011
next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Russel Winder Wrote:

 gitk uses the Tk widget set which looks hideous -- at least on my Ubuntu
 and Debian systems.  I now use gitg which appears to have the same
 functionality, but looks almost acceptable.  There is also git-gui.

Funny thing, gitk looks better on Windows. I don't care though. My friend ends up with font that is barely readable. Also there is giggle: http://live.gnome.org/giggle I like the name, but I still prefer gitk.
Jan 08 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-01-08 16:01, Russel Winder wrote:
 On Sat, 2011-01-08 at 15:38 +0100, Jacob Carlborg wrote:
 On 2011-01-06 21:12, Michel Fortin wrote:

 Also
 when I want an overview with git I just type gitk on the command line to
 bring a window where I can browser the graph of forks, merges and
 commits and see the diff for each commit. Here's what gitk looks like:
 <http://michael-prokop.at/blog/img/gitk.png>


gitk uses the Tk widget set which looks hideous -- at least on my Ubuntu and Debian systems. I now use gitg which appears to have the same functionality, but looks almost acceptable. There is also git-gui.

Doesn't the Tk widget set look hideous on all platforms. I can't understand why both Mercurial and git have chosen to use Tk for the GUI. -- /Jacob Carlborg
Jan 08 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Jesse Phillips wrote:
 Walter Bright Wrote:
 One thing I like a lot about svn is this:
 
 http://www.dsource.org/projects/dmd/changeset/291

You mean this: https://github.com/braddr/dmd/commit/f1fde96227394f926da5841db4f0f4c608b2e7b2

Yes, exactly. Good.
 One thing I would dearly like is to be able to merge branches using meld.
 
 http://meld.sourceforge.net/

Git does not have its own merge tool. You are free to use meld. Though there is gitmerge which can run meld as the merge tool.

Jan 06 2011
prev sibling next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 06.01.2011 20:46, schrieb Walter Bright:
 Russel Winder wrote:
 Pity, because using one of Mercurial, Bazaar or Git instead of
 Subversion is likely the best and fastest way of getting more quality
 contributions to review. Although only anecdotal in every case where a
 team has switched to DVCS from CVCS -- except in the case of closed
 projects, obviously -- it has opened things up to far more people to
 provide contributions. Subversion is probably now the single biggest
 barrier to getting input on system evolution.

A couple months back, I did propose moving to git on the dmd internals mailing list, and nobody was interested. One thing I like a lot about svn is this: http://www.dsource.org/projects/dmd/changeset/291 where the web view will highlight the revision's changes. Does git or mercurial do that? The other thing I like a lot about gif is it sends out emails for each checkin.

It's not SVN but trac doing this. And trac's mercurial plugin seems to support that as well: http://trac.edgewall.org/wiki/TracMercurial#MercurialChangesets Bitbucket also supports that kind of view, see for example: https://bitbucket.org/goshawk/gdc/changeset/44b6978e5f6c The GitPlugin should support that as well, if I interpret the feature list correctly: http://trac-hacks.org/wiki/GitPlugin Dsource seems to support both git and mercurial, but I don't know which projects use them, else I'd them as examples to see how those trac plugins work in real life. Cheers, - Daniel
Jan 06 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:ig57ar$1gn9$1 digitalmars.com...
 Am 06.01.2011 20:46, schrieb Walter Bright:
 Russel Winder wrote:
 Pity, because using one of Mercurial, Bazaar or Git instead of
 Subversion is likely the best and fastest way of getting more quality
 contributions to review. Although only anecdotal in every case where a
 team has switched to DVCS from CVCS -- except in the case of closed
 projects, obviously -- it has opened things up to far more people to
 provide contributions. Subversion is probably now the single biggest
 barrier to getting input on system evolution.

A couple months back, I did propose moving to git on the dmd internals mailing list, and nobody was interested. One thing I like a lot about svn is this: http://www.dsource.org/projects/dmd/changeset/291 where the web view will highlight the revision's changes. Does git or mercurial do that? The other thing I like a lot about gif is it sends out emails for each checkin.

It's not SVN but trac doing this. And trac's mercurial plugin seems to support that as well: http://trac.edgewall.org/wiki/TracMercurial#MercurialChangesets Bitbucket also supports that kind of view, see for example: https://bitbucket.org/goshawk/gdc/changeset/44b6978e5f6c The GitPlugin should support that as well, if I interpret the feature list correctly: http://trac-hacks.org/wiki/GitPlugin Dsource seems to support both git and mercurial, but I don't know which projects use them, else I'd them as examples to see how those trac plugins work in real life.

DDMD uses Mercurial on DSource: http://www.dsource.org/projects/ddmd
Jan 06 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 06.01.2011 23:26, schrieb Nick Sabalausky:
 "Daniel Gibson"<metalcaedes gmail.com>  wrote in message
 news:ig57ar$1gn9$1 digitalmars.com...
 Am 06.01.2011 20:46, schrieb Walter Bright:
 Russel Winder wrote:
 Pity, because using one of Mercurial, Bazaar or Git instead of
 Subversion is likely the best and fastest way of getting more quality
 contributions to review. Although only anecdotal in every case where a
 team has switched to DVCS from CVCS -- except in the case of closed
 projects, obviously -- it has opened things up to far more people to
 provide contributions. Subversion is probably now the single biggest
 barrier to getting input on system evolution.

A couple months back, I did propose moving to git on the dmd internals mailing list, and nobody was interested. One thing I like a lot about svn is this: http://www.dsource.org/projects/dmd/changeset/291 where the web view will highlight the revision's changes. Does git or mercurial do that? The other thing I like a lot about gif is it sends out emails for each checkin.

It's not SVN but trac doing this. And trac's mercurial plugin seems to support that as well: http://trac.edgewall.org/wiki/TracMercurial#MercurialChangesets Bitbucket also supports that kind of view, see for example: https://bitbucket.org/goshawk/gdc/changeset/44b6978e5f6c The GitPlugin should support that as well, if I interpret the feature list correctly: http://trac-hacks.org/wiki/GitPlugin Dsource seems to support both git and mercurial, but I don't know which projects use them, else I'd them as examples to see how those trac plugins work in real life.

DDMD uses Mercurial on DSource: http://www.dsource.org/projects/ddmd

http://www.dsource.org/projects/ddmd/changeset?new=rt%40185%3A13cf8da225ce&old=rt%40183%3A190ba98276b3 "Trac detected an internal error:" looks like dsource uses an old/broken version of the mercurial plugin. But normally it *should* work, I think.
Jan 06 2011
parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Daniel Gibson wrote:

 Am 06.01.2011 23:26, schrieb Nick Sabalausky:
 "Daniel Gibson"<metalcaedes gmail.com>  wrote in message
 news:ig57ar$1gn9$1 digitalmars.com...
 Am 06.01.2011 20:46, schrieb Walter Bright:
 Russel Winder wrote:
 Pity, because using one of Mercurial, Bazaar or Git instead of
 Subversion is likely the best and fastest way of getting more quality
 contributions to review. Although only anecdotal in every case where a
 team has switched to DVCS from CVCS -- except in the case of closed
 projects, obviously -- it has opened things up to far more people to
 provide contributions. Subversion is probably now the single biggest
 barrier to getting input on system evolution.

A couple months back, I did propose moving to git on the dmd internals mailing list, and nobody was interested. One thing I like a lot about svn is this: http://www.dsource.org/projects/dmd/changeset/291 where the web view will highlight the revision's changes. Does git or mercurial do that? The other thing I like a lot about gif is it sends out emails for each checkin.

It's not SVN but trac doing this. And trac's mercurial plugin seems to support that as well: http://trac.edgewall.org/wiki/TracMercurial#MercurialChangesets Bitbucket also supports that kind of view, see for example: https://bitbucket.org/goshawk/gdc/changeset/44b6978e5f6c The GitPlugin should support that as well, if I interpret the feature list correctly: http://trac-hacks.org/wiki/GitPlugin Dsource seems to support both git and mercurial, but I don't know which projects use them, else I'd them as examples to see how those trac plugins work in real life.

DDMD uses Mercurial on DSource: http://www.dsource.org/projects/ddmd


 "Trac detected an internal error:"
 looks like dsource uses an old/broken version of the mercurial plugin.
 But normally it *should* work, I think.

This works: http://www.dsource.org/projects/ddmd/changeset/183:190ba98276b3
Jan 06 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/6/11 4:26 PM, Nick Sabalausky wrote:
 DDMD uses Mercurial on DSource: http://www.dsource.org/projects/ddmd

The ready availability of Mercurial on dsource.org plus Don's inclination to use Mercurial just tipped the scale for me. We should do all we can to make Don's and other developers' life easier, and being able to work on multiple fixes at a time is huge. We should create a new Mercurial repository. I suggest we call it digitalmars because the current "phobos" svn repo contains a lot of stuff that's not phobos-related. Andrei
Jan 06 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei:

 The ready availability of Mercurial on dsource.org plus Don's 
 inclination to use Mercurial just tipped the scale for me. We should do 
 all we can to make Don's and other developers' life easier, and being 
 able to work on multiple fixes at a time is huge.

Probably both Mercurial and Git are a little improvement over the current situation. It's also a way to improve D image, making it look a little more open source. I hope a fat "Fork me!" button will be visible on a web page :-) Bye, bearophile
Jan 06 2011
prev sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 1/6/11 11:47 PM, Andrei Alexandrescu wrote:
 Mercurial on dsource.org …

Personally, I'd really like to persuade Walter, you, and whoever else actually decides this to consider hosting the main repository at an external place like GitHub or Mercurial, because DSource has been having some real troubles with stability, although it got slightly better again recently. The problem is somewhat alleviated when using a DVCS, but having availabilities the main source repositories is not quite the best form of advertisement for a language. Additionally, the UI of GitHub supports the scenario where only a few people (or Walter alone) actually have commit/push access to the main repository really well through cheap forks which stay logically connected to he main repository and merge requests. The ability to make comments on specific (lines in) commits, also in combination with pull requests, is awesome as well. I would also like to suggest Git over Mercurial, though this is mostly personal preference – it is used more widely, it has GitHub and Gitorious (I'm having a hard time finding Bitbucket comparable personally), it's proven to work well in settings where the main tree is managed by a single person (->Linux), it tries not artificially restricting you as much as possible (something I imagine Walter might like), … – but again, it's probably a matter of taste, I don't want to start a flamewar here. The most important thing to me is, however, that I'd really like to see a general shift in the way D development is done towards more contributor-friendliness. I can only bow to Walter as a very capable and experienced compiler writer, but as it was discussed several times here on the list as well, in my opinion D has reached a point where it desperately needs to win new contributors to the whole ecosystem. There is a reason why other open source projects encourage you to write helpful commit messages, and yet we don't even have tags for releases (!) in the DMD repository. I didn't intend to offend anybody at all, but I'd really hate to see D2 failing to »take off« for reasons like this… David
Jan 06 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"David Nadlinger" <see klickverbot.at> wrote in message 
news:ig5n74$2vu3$1 digitalmars.com...
 On 1/6/11 11:47 PM, Andrei Alexandrescu wrote:
 Mercurial on dsource.org .

Personally, I'd really like to persuade Walter, you, and whoever else actually decides this to consider hosting the main repository at an external place like GitHub or Mercurial, because DSource has been having some real troubles with stability, although it got slightly better again recently. The problem is somewhat alleviated when using a DVCS, but having availabilities the main source repositories is not quite the best form of advertisement for a language. Additionally, the UI of GitHub supports the scenario where only a few people (or Walter alone) actually have commit/push access to the main repository really well through cheap forks which stay logically connected to he main repository and merge requests. The ability to make comments on specific (lines in) commits, also in combination with pull requests, is awesome as well. I would also like to suggest Git over Mercurial, though this is mostly personal preference - it is used more widely, it has GitHub and Gitorious (I'm having a hard time finding Bitbucket comparable personally), it's proven to work well in settings where the main tree is managed by a single person (->Linux), it tries not artificially restricting you as much as possible (something I imagine Walter might like), . - but again, it's probably a matter of taste, I don't want to start a flamewar here.

I've never used github, but I have used bitbucket and I truly, truly hate it. Horribly implemented site and an honest pain in the ass to use.
Jan 06 2011
parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Nick Sabalausky Wrote:

 I've never used github, but I have used bitbucket and I truly, truly hate 
 it. Horribly implemented site and an honest pain in the ass to use.

I've never really used bitbucket, but I don't know how it could be any worse to use then dsource. If you ignore all the features Dsource doesn't have, it feels about the same to me.
Jan 06 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Jesse Phillips" <jessekphillips+D gmail.com> wrote in message 
news:ig62kh$h71$1 digitalmars.com...
 Nick Sabalausky Wrote:

 I've never used github, but I have used bitbucket and I truly, truly hate
 it. Horribly implemented site and an honest pain in the ass to use.

I've never really used bitbucket, but I don't know how it could be any worse to use then dsource. If you ignore all the features Dsource doesn't have, it feels about the same to me.

The features in DSource generally *just work* (except when the whole server is down, of course). With BitBucket, I tried to post a bug report for xfbuild one time (and I'm pretty sure there was another project too) and the damn thing just wouldn't work. And the text-entry box was literally two lines high. Kept trying and eventually I got one post through, but it was all garbled. So I kept trying more and nothing would show up, so I gave up. Came back a day later and there were a bunch of duplicate posts. Gah. And yea, that was just the bug tracker, but it certainly didn't instill any confidence in anything else about the site. And I'm not certain, but I seem to recall some idiotic pains in the ass when trying to sign up for an account, too. With DSource, as long as the server is up, everything's always worked for me...Well...except now that I think of it, I've never been able to edit the roadmap or edit the entries in the bug-tracker's "components" field for any of the projects I admin. Although, I can live without that.
Jan 07 2011
parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Oh, yeah that would be annoying. I haven't done much with the github website
but haven't had issues like that.

About the only thing that makes github a little annoying at first is that you
have to use public/private key pairs to do any pushing to a repo. But I haven't
had any issues creating/using them from Linux/Windows. You can associate
multiple public keys with your account so you don't need to take your private
key everywhere with you. They can also be deleted so you could have temporary
ones.

Nick Sabalausky Wrote:

 The features in DSource generally *just work* (except when the whole server 
 is down, of course). With BitBucket, I tried to post a bug report for 
 xfbuild one time (and I'm pretty sure there was another project too) and the 
 damn thing just wouldn't work. And the text-entry box was literally two 
 lines high. Kept trying and eventually I got one post through, but it was 
 all garbled. So I kept trying more and nothing would show up, so I gave up. 
 Came back a day later and there were a bunch of duplicate posts. Gah.
 
 And yea, that was just the bug tracker, but it certainly didn't instill any 
 confidence in anything else about the site. And I'm not certain, but I seem 
 to recall some idiotic pains in the ass when trying to sign up for an 
 account, too.
 
 With DSource, as long as the server is up, everything's always worked for 
 me...Well...except now that I think of it, I've never been able to edit the 
 roadmap or edit the entries in the bug-tracker's "components" field for any 
 of the projects I admin. Although, I can live without that.
 
 

Jan 07 2011
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 07/01/2011 00:34, David Nadlinger wrote:
 On 1/6/11 11:47 PM, Andrei Alexandrescu wrote:
 Mercurial on dsource.org …

Personally, I'd really like to persuade Walter, you, and whoever else actually decides this to consider hosting the main repository at an external place like GitHub or Mercurial, because DSource has been having some real troubles with stability, although it got slightly better again recently. The problem is somewhat alleviated when using a DVCS, but having availabilities the main source repositories is not quite the best form of advertisement for a language. Additionally, the UI of GitHub supports the scenario where only a few people (or Walter alone) actually have commit/push access to the main repository really well through cheap forks which stay logically connected to he main repository and merge requests. The ability to make comments on specific (lines in) commits, also in combination with pull requests, is awesome as well.

I have to agree and reiterate this point. The issue of whether it is worthwhile for D to move to a DVCS (and which one of the two) is definitely a good thing to consider, but the issue of DSource vs. other code hosting sites is also quite a relevant one. (And not just for DMD but for any project.) I definitely thank Brad for his support and work on DSource, however I question if it is the best way to go for medium or large-sized D projects. Other hosting sites will simply offer better/more features and/or support, stability, less bugs, spam-protection, etc.. What we have here is exactly the same issue of NIH syndrome vs DRY, but applied to hosting and development infrastructure instead of the code itself. But I think the principle applies just the same. -- Bruno Medeiros - Software Engineer
Jan 28 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 28.01.2011 14:07, schrieb Bruno Medeiros:
 On 07/01/2011 00:34, David Nadlinger wrote:
 On 1/6/11 11:47 PM, Andrei Alexandrescu wrote:
 Mercurial on dsource.org …

Personally, I'd really like to persuade Walter, you, and whoever else actually decides this to consider hosting the main repository at an external place like GitHub or Mercurial, because DSource has been having some real troubles with stability, although it got slightly better again recently. The problem is somewhat alleviated when using a DVCS, but having availabilities the main source repositories is not quite the best form of advertisement for a language. Additionally, the UI of GitHub supports the scenario where only a few people (or Walter alone) actually have commit/push access to the main repository really well through cheap forks which stay logically connected to he main repository and merge requests. The ability to make comments on specific (lines in) commits, also in combination with pull requests, is awesome as well.

I have to agree and reiterate this point. The issue of whether it is worthwhile for D to move to a DVCS (and which one of the two) is definitely a good thing to consider, but the issue of DSource vs. other code hosting sites is also quite a relevant one. (And not just for DMD but for any project.) I definitely thank Brad for his support and work on DSource, however I question if it is the best way to go for medium or large-sized D projects. Other hosting sites will simply offer better/more features and/or support, stability, less bugs, spam-protection, etc.. What we have here is exactly the same issue of NIH syndrome vs DRY, but applied to hosting and development infrastructure instead of the code itself. But I think the principle applies just the same.

D has already moved to github, see D.announce :)
Jan 28 2011
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 28/01/2011 13:13, Daniel Gibson wrote:
 Am 28.01.2011 14:07, schrieb Bruno Medeiros:
 On 07/01/2011 00:34, David Nadlinger wrote:
 On 1/6/11 11:47 PM, Andrei Alexandrescu wrote:
 Mercurial on dsource.org …

Personally, I'd really like to persuade Walter, you, and whoever else actually decides this to consider hosting the main repository at an external place like GitHub or Mercurial, because DSource has been having some real troubles with stability, although it got slightly better again recently. The problem is somewhat alleviated when using a DVCS, but having availabilities the main source repositories is not quite the best form of advertisement for a language. Additionally, the UI of GitHub supports the scenario where only a few people (or Walter alone) actually have commit/push access to the main repository really well through cheap forks which stay logically connected to he main repository and merge requests. The ability to make comments on specific (lines in) commits, also in combination with pull requests, is awesome as well.

I have to agree and reiterate this point. The issue of whether it is worthwhile for D to move to a DVCS (and which one of the two) is definitely a good thing to consider, but the issue of DSource vs. other code hosting sites is also quite a relevant one. (And not just for DMD but for any project.) I definitely thank Brad for his support and work on DSource, however I question if it is the best way to go for medium or large-sized D projects. Other hosting sites will simply offer better/more features and/or support, stability, less bugs, spam-protection, etc.. What we have here is exactly the same issue of NIH syndrome vs DRY, but applied to hosting and development infrastructure instead of the code itself. But I think the principle applies just the same.

D has already moved to github, see D.announce :)

I know, I know. :) (I am up-to-date on D.announce, just not on "D" and "D.bugs") I still wanted to make that point though. First, for retrospection, but also because it may still apply to a few other DSource projects (current or future ones). -- Bruno Medeiros - Software Engineer
Jan 28 2011
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 28/01/2011 21:14, retard wrote:
 Fri, 28 Jan 2011 15:03:24 +0000, Bruno Medeiros wrote:

 I know, I know. :)  (I am up-to-date on D.announce, just not on "D" and
 "D.bugs")
 I still wanted to make that point though. First, for retrospection, but
 also because it may still apply to a few other DSource projects (current
 or future ones).

You don't need to read every post here. Reading every bug report is just stupid.. but it's not my problem. It just means that the rest of us have less competition in everyday situations (getting women, work offers, and so on)

I don't read every bug report, I only (try to) read the titles and see if it's something interesting, for example something that might impact the design of the language and is just not a pure implementation issue. Still, yes, I may be spending too much time on the NG (especially for someone who doesn't skip the 8 hours of sleep), but the bottleneck at the moment is writing posts, especially those that involve arguments. They are an order of magnitude more "expensive" than reading posts. -- Bruno Medeiros - Software Engineer
Feb 01 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-01-06 23:26, Nick Sabalausky wrote:
 "Daniel Gibson"<metalcaedes gmail.com>  wrote in message
 news:ig57ar$1gn9$1 digitalmars.com...
 Am 06.01.2011 20:46, schrieb Walter Bright:
 Russel Winder wrote:
 Pity, because using one of Mercurial, Bazaar or Git instead of
 Subversion is likely the best and fastest way of getting more quality
 contributions to review. Although only anecdotal in every case where a
 team has switched to DVCS from CVCS -- except in the case of closed
 projects, obviously -- it has opened things up to far more people to
 provide contributions. Subversion is probably now the single biggest
 barrier to getting input on system evolution.

A couple months back, I did propose moving to git on the dmd internals mailing list, and nobody was interested. One thing I like a lot about svn is this: http://www.dsource.org/projects/dmd/changeset/291 where the web view will highlight the revision's changes. Does git or mercurial do that? The other thing I like a lot about gif is it sends out emails for each checkin.

It's not SVN but trac doing this. And trac's mercurial plugin seems to support that as well: http://trac.edgewall.org/wiki/TracMercurial#MercurialChangesets Bitbucket also supports that kind of view, see for example: https://bitbucket.org/goshawk/gdc/changeset/44b6978e5f6c The GitPlugin should support that as well, if I interpret the feature list correctly: http://trac-hacks.org/wiki/GitPlugin Dsource seems to support both git and mercurial, but I don't know which projects use them, else I'd them as examples to see how those trac plugins work in real life.

DDMD uses Mercurial on DSource: http://www.dsource.org/projects/ddmd

I've been using Mercurial for all my projects on dsource and some other projects not on dsource. All DWT projects uses Mercurial as well. -- /Jacob Carlborg
Jan 08 2011
prev sibling parent Eric Poggel <dnewsgroup2 yage3d.net> writes:
On 1/6/2011 3:03 PM, Daniel Gibson wrote:
 Dsource seems to support both git and mercurial, but I don't know which
 projects use them, else I'd them as examples to see how those trac
 plugins work in real life.

I stumbpled across this url the other day: http://hg.dsource.org/ Seems to list mercurial projects. I couldn't find a similar one for git.
Jan 06 2011
prev sibling next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 06/01/11 19:46, Walter Bright wrote:
 One thing I like a lot about svn is this:

 http://www.dsource.org/projects/dmd/changeset/291

That's Trac, not SVN doing it - all other version control systems do a similar thing.
 where the web view will highlight the revision's changes. Does git or
 mercurial do that? The other thing I like a lot about gif is it sends
 out emails for each checkin.

This is easily doable with both mercurial and git. If you use a tool like bitbucket or github (which I *highly* recommend you do, opens up a huge community to you, I know of several cases where projects have been discovered through them and gained contributors etc).
 One thing I would dearly like is to be able to merge branches using meld.

 http://meld.sourceforge.net/

There's guides for doing this in both mercurial and git, you generally just run one command one time and forget about it, any time you do git/hg merge it will then automatically use meld or any other tool you discover. -- Robert http://octarineparrot.com/
Jan 06 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Robert Clipsham" <robert octarineparrot.com> wrote in message 
news:ig58tk$24bn$1 digitalmars.com...
 On 06/01/11 19:46, Walter Bright wrote:
 One thing I like a lot about svn is this:

 http://www.dsource.org/projects/dmd/changeset/291

That's Trac, not SVN doing it - all other version control systems do a similar thing.
 where the web view will highlight the revision's changes. Does git or
 mercurial do that? The other thing I like a lot about gif is it sends
 out emails for each checkin.

This is easily doable with both mercurial and git. If you use a tool like bitbucket or github (which I *highly* recommend you do, opens up a huge community to you, I know of several cases where projects have been discovered through them and gained contributors etc).

I would STRONGLY recommend against using any site that requires a valid non-mailinator email address just to do basic things like post a bug report. I'm not sure exactly which ones are and aren't like that, but many free project hosting sites are like that and it's an absolutely inexcusable barrier. And of course everyone knows how I'd feel about any site that required JS for anything that obviously didn't need JS. ;) One other random thought: I'd really hate to use a system that didn't have short sequential changeset identifiers. I think Hg does have that, although I don't think all Hg interfaces actually use it, just some.
Jan 06 2011
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Nick Sabalausky wrote:
 One other random thought: I'd really hate to use a system that didn't h=

 short sequential changeset identifiers. I think Hg does have that, alth=

 I don't think all Hg interfaces actually use it, just some.
=20

sequential numbers). AFAIK all commands use them (I've never used a command that did not). Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jan 07 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday 07 January 2011 02:09:31 Russel Winder wrote:
 On Thu, 2011-01-06 at 11:46 -0800, Walter Bright wrote:
 A couple months back, I did propose moving to git on the dmd internals
 mailing list, and nobody was interested.

That surprises me. Shifting from Subversion to any of Mercurial, Bazaar or Git, is such a huge improvement in tooling. Especially for support of feature branches.

Part of that was probably because not that many people pay attention to the dmd internals mailing list. I don't recall seeing that post, and I do pay at least some attention to that list. I would have been for it, but then again, I'm also not one of the dmd developers - not that there are many. Personally, I'd love to see dmd, druntime, and Phobos switch over to git, since that's what I typically use. It would certainly be an improvement over subversion. But I can't compare it to other systems such as Mercurial and Bazaar, because I've never used them. Really, for me personally, git works well enough that I've had no reason to check any others out. I can attest though that git is a huge improvement over subversion. Before I started using git, I almost never used source control on my own projects, because it was too much of a pain. With git, it's extremely easy to set up a new repository, it doesn't pollute the whole source tree with source control files, and it doesn't force me to have a second copy of the repository somewhere else. So, thanks to git, I now use source control all the time. - Jonathan M Davis
Jan 07 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Russel Winder wrote:
 One thing I would dearly like is to be able to merge branches using meld.

 http://meld.sourceforge.net/

Why?

Because meld makes it easy to review, selectively merge, and do a bit of editing all in one go.
 Mercurial, Bazaar and Git all support a variety of three-way merge tools
 including meld, but the whole point of branching and merging is that you
 don't do it manually -- except in Subversion where merging branching
 remains a problem.

But I want to do it manually.
 With Mercurial, Bazaar and Git, if you accept a changeset from a branch
 you jsut merge it, e.g.
 
 	git merge some-feature-branch
 
 job done.  If you want to amend the changeset before committing to HEAD
 then create a feature branch, merge the incoming changeset to the
 feature branch, work on it till satisfied, merge to HEAD.
 
 The only time I used meld these days is to process merge conflicts, not
 to handle merging per se. 

I've always been highly suspicious of the auto-detection of a 3 way merge conflict.
Jan 07 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Russel Winder wrote:
 Walter,
 
 On Fri, 2011-01-07 at 10:54 -0800, Walter Bright wrote:
 Russel Winder wrote:
 One thing I would dearly like is to be able to merge branches using meld.

 http://meld.sourceforge.net/


all in one go.

Hummm . . . these days that is seen as being counter-productive to having a full and complete record of the evolution of a project. These days it is assumed that a reviewed changeset is committed as is and then further amendments made as a separate follow-up changeset. A core factor here is of attribution and publicity of who did what. By committing reviewed changesets before amending them, the originator of the changeset is noted as the author of the changeset in the history. As I understand the consequences of the above system, you are always shown as the committer of every change -- but I may just have got this wrong, I haven't actually looked at the DMD repository.

I never thought of that.
 Mercurial, Bazaar and Git all support a variety of three-way merge tools
 including meld, but the whole point of branching and merging is that you
 don't do it manually -- except in Subversion where merging branching
 remains a problem.


Clearly I don't understand your workflow. When I used Subversion, its merge capabilities were effectively none -- and as I understand it, things have not got any better in reality despite all the publicity about new merge support. So handling changesets from branches and elsewhere always had to be a manual activity. Maintaining a truly correct history was effectively impossible. Now with Bazaar, Mercurial and Git, merge is so crucial to the very essence of what these systems do that I cannot conceive of manually merging except to resolve actual conflicts. Branch and merge is so trivially easy in all of Bazaar, Mercurial and Git, that it changes workflows. Reviewing changesets is still a crucially important thing, but merging them should not be part of that process.

I never thought of it that way before.
 With Mercurial, Bazaar and Git, if you accept a changeset from a branch
 you jsut merge it, e.g.

 	git merge some-feature-branch

 job done.  If you want to amend the changeset before committing to HEAD
 then create a feature branch, merge the incoming changeset to the
 feature branch, work on it till satisfied, merge to HEAD.

 The only time I used meld these days is to process merge conflicts, not
 to handle merging per se. 


I have always been highly suspicious that compilers can optimize my code better than I can ;-)

You should be!
Jan 08 2011
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article
 Russel Winder wrote:
 One thing I would dearly like is to be able to merge branches using meld.

 http://meld.sourceforge.net/

Why?

all in one go.

I whole heartedly agree with this.
Jan 08 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 22 Jan 2011 08:35:55 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 The only real problem I've run into (so far) is the sunbird calendar has  
 been unceremoniously dumped from Ubuntu. The data file for it is in some  
 crappy binary format, so poof, there goes all my calendar data.

Hi Walter, have you seen this yet? It's an article on how to import your calendar data in Lightning, the official Thunderbird calendar extension. I hope it'll help you: http://brizoma.wordpress.com/2010/05/04/sunbird-and-lightning-removed-from-ubuntu-10-04-lucid-lynx/ -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 22 2011
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 22 Jan 2011 13:12:26 -0800, Walter Bright wrote:

 Vladimir Panteleev wrote:
 http://brizoma.wordpress.com/2010/05/04/sunbird-and-lightning-removed-


 
 Thanks for finding that. But I think I'll stick for now with the ipod's
 calendar. It's more useful anyway, as it moves with me.

Does the new Ubuntu overall work better than the old one? Would be amazing if the media players are still all broken.
Jan 22 2011
prev sibling parent retard <re tard.com.invalid> writes:
Sat, 22 Jan 2011 14:47:48 -0800, Walter Bright wrote:

 retard wrote:
 Does the new Ubuntu overall work better than the old one? Would be
 amazing if the media players are still all broken.

I haven't tried the sound yet, but the video playback definitely is better. Though the whole screen flashes now and then, like the video mode is being reset badly. This is new behavior.

Ubuntu probably uses Compiz if you have enabled desktop effects. This might not work with ati's (open source) drivers. Turning Compiz off makes it use a "safer" 2d engine. In Gnome the setting can be changed here http://www.howtoforge.com/enabling-compiz-fusion-on-an-ubuntu-10.10- desktop-nvidia-geforce-8200-p2 It's the "none" option in the second figure.
Jan 22 2011
prev sibling parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Nick Sabalausky wrote:

 "Caligo" <iteronvexor gmail.com> wrote in message
 news:mailman.451.1294306555.4748.digitalmars-d puremagic.com...
 On Thu, Jan 6, 2011 at 12:28 AM, Walter Bright
 <newshound2 digitalmars.com>wrote:

 That's pretty much what I'm afraid of, losing my grip on how the whole
 thing works if there are multiple dmd committers.

 Perhaps using a modern SCM like Git might help?  Everyone could have
 (and

one of the managers would then review the changes and pull and merge with the main branch. It works great; just checkout out Rubinius on Github to see what I mean: https://github.com/evanphx/rubinius

I'm not sure I see how that's any different from everyone having "create and submit a patch" rights, and then having Walter or one of the managers review the changes and merge/patch with the main branch.

There isn't because it is basically the same workflow. The reason why people would prefer git style fork and merge over sending svn patches is because these tools do the same job much better. github increases the usability further and give you nice pr for free. otoh I understand that it's not exactly attractive to invest time to replace something that also works right now.
Jan 06 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-01-06 07:28, Walter Bright wrote:
 Nick Sabalausky wrote:
 Automatically accepting all submissions immediately into the main line
 with no review isn't a good thing either. In that article he's
 complaining about MS, but MS is notorious for ignoring all non-MS
 input, period. D's already light-years ahead of that. Since D's purely
 volunteer effort, and with a lot of things to be done, sometimes
 things *are* going to tale a while to get in. But there's just no way
 around that without major risks to quality. And yea Walter could grant
 main-line DMD commit access to others, but then we'd be left with a
 situation where no single lead dev understands the whole program
 inside and out - and when that happens to projects, that's inevitably
 the point where it starts to go downhill.

That's pretty much what I'm afraid of, losing my grip on how the whole thing works if there are multiple dmd committers.

That is very understandable. Maybe we can have a look at the linux kernel development process: http://ldn.linuxfoundation.org/book/how-participate-linux-community As how I understands it, Linus Torvalds day to day work on the linux kerenl mostly consist of merging changes made in developer branches into the main branch.
 On the bright (!) side, Brad Roberts has gotten the test suite in shape
 so that anyone developing a patch can run it through the full test
 suite, which is a prerequisite to getting it folded in.

Has this been announced (somewhere else than the DMD mailing list)? Where can one get the test suite? It should be available and easy to find and with instructions how to run it. Somewhere on the Digitalmars site or/and perhaps released with the DMD source code?
 In the last release, most of the patches in the changelog were done by
 people other than myself, although yes, I vet and double check them all
 before committing them.

-- /Jacob Carlborg
Jan 06 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
Jacob Carlborg wrote:
 Has this been announced (somewhere else than the DMD mailing list)? 
 Where can one get the test suite? It should be available and easy to 
 find and with instructions how to run it. Somewhere on the Digitalmars 
 site or/and perhaps released with the DMD source code?

It's part of dmd on svn: http://www.dsource.org/projects/dmd/browser/trunk/test
Jan 06 2011
prev sibling next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Russel Winder Wrote:

 Whilst I concur (massively) that Subversion is no longer the correct
 tool for collaborative working, especially on FOSS projects, but also
 for proprietary ones, I am not sure Git is the best choice of tool.
 Whilst Git appears to have the zeitgeist, Mercurial and Bazaar are
 actually much easier to work with.  Where Git has GitHub, Mercurial has
 BitBucket, and Bazaar has Launchpad.

First I think one must be convinced to move. Then that using a social site adds even more. Then we can discuss which one to use. My personal choice is git because I don't use the others. And this was a great read: http://progit.org/book/
Jan 06 2011
prev sibling next sibling parent Brad Roberts <braddr slice-2.puremagic.com> writes:
On Thu, 6 Jan 2011, Andrei Alexandrescu wrote:

 On 1/6/11 4:26 PM, Nick Sabalausky wrote:
 DDMD uses Mercurial on DSource: http://www.dsource.org/projects/ddmd

The ready availability of Mercurial on dsource.org plus Don's inclination to use Mercurial just tipped the scale for me. We should do all we can to make Don's and other developers' life easier, and being able to work on multiple fixes at a time is huge. We should create a new Mercurial repository. I suggest we call it digitalmars because the current "phobos" svn repo contains a lot of stuff that's not phobos-related. Andrei

Personally, I'd prefer to git over mecurial, which dsource also supports. But, really, I'd prefer github over dsource (sorry, BradA) for stability and just generally much more usable site. My general problem with the switch to a different SCM of any sort: 1) the history of the current source is a mess. a) lack of tags for releases b) logical merges have all been done as individual commits 2) walter's workflow meaning that he'll won't use the scm merge facilities. He manually merges everything. None of this is really a problem, it just becomes a lot more visible when using a system that encourages keeping a very clean history and the use of branches and merging. My 2 cents, Brad
Jan 06 2011
prev sibling next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 07.01.2011 03:20, schrieb Caligo:
 On Thu, Jan 6, 2011 at 5:50 AM, Russel Winder <russel russel.org.uk
 <mailto:russel russel.org.uk>> wrote:

     Whilst I concur (massively) that Subversion is no longer the correct
     tool for collaborative working, especially on FOSS projects, but also
     for proprietary ones, I am not sure Git is the best choice of tool.
     Whilst Git appears to have the zeitgeist, Mercurial and Bazaar are
     actually much easier to work with.  Where Git has GitHub, Mercurial has
     BitBucket, and Bazaar has Launchpad.

     --
     Russel.
     =============================================================================
     Dr Russel Winder      t: +44 20 7585 2200   voip:
     sip:russel.winder ekiga.net <mailto:sip%3Arussel.winder ekiga.net>
     41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
     <mailto:russel russel.org.uk>
     London SW11 1EN, UK   w: www.russel.org.uk <http://www.russel.org.uk>
       skype: russel_winder


 BitBucket has copied almost everything from Github, and I don't understand how
 they've never been sued.

 http://dev.pocoo.org/~blackbird/github-vs-bitbucket/bitbucket.html

Yeah, see also: http://schacon.github.com/bitbucket.html by the same author When this rant was new I read a page that listed where Github stole their ideas and designs (Sourceforce for example), but I can't find it anymore. This rant was bullshit, as even the author seems to have accepted. I don't understand why people still mirror and link this crap.
Jan 06 2011
prev sibling next sibling parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Nick Sabalausky wrote:

 "Caligo" <iteronvexor gmail.com> wrote in message
 news:mailman.461.1294366839.4748.digitalmars-d puremagic.com...
 BitBucket has copied almost everything from Github, and I don't
 understand how they've never been sued.

 http://dev.pocoo.org/~blackbird/github-vs-bitbucket/bitbucket.html

That page looks like the VCS equivalent of taking pictures of sandwiches from two different restaurants and then bitching "Oh my god! What a blatant copy! Look, they both have meat, lettuce and condiments between slices of bread! And they BOTH have the lettuce on top of the meat! What a pathetic case of plagiarism!" Bah.

Really? When I first visited bitbucket, I though this was from the makers of github launching a hg site from their github code, with some slightly altered css. There is quite a difference between github, gitorious and launchpad on the other hand.
Jan 07 2011
parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Lutger Blijdestijn wrote:

 Nick Sabalausky wrote:
 
 "Caligo" <iteronvexor gmail.com> wrote in message
 news:mailman.461.1294366839.4748.digitalmars-d puremagic.com...
 BitBucket has copied almost everything from Github, and I don't
 understand how they've never been sued.

 http://dev.pocoo.org/~blackbird/github-vs-bitbucket/bitbucket.html

That page looks like the VCS equivalent of taking pictures of sandwiches from two different restaurants and then bitching "Oh my god! What a blatant copy! Look, they both have meat, lettuce and condiments between slices of bread! And they BOTH have the lettuce on top of the meat! What a pathetic case of plagiarism!" Bah.

Really? When I first visited bitbucket, I though this was from the makers of github launching a hg site from their github code, with some slightly altered css. There is quite a difference between github, gitorious and launchpad on the other hand.

To be clear: not that I care much, good ideas should be copied (or, from your perspective, bad ideas could ;) )
Jan 07 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 19 Jan 2011 23:18:13 +0200, Gour <gour atmarama.net> wrote:

 On Wed, 19 Jan 2011 19:15:54 +0000 (UTC)
 retard <re tard.com.invalid> wrote:

 "..your Ubuntu version isn't supported anymore. They might have
 already removed the package repositories for unsupported versions and
 that might indeed lead to problems"

That's why we wrote it would be better to use some rolling release like Archlinux where distro cannot become so outdated that it's not possible to upgrade easily.

Walter needs something he can install and get on with compiler hacking. ArchLinux sounds quite far from that. I'd just recommend upgrading to an Ubuntu LTS (to also minimize the requirement of familiarizing yourself with a new distribution). -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 19 2011
prev sibling parent Brad Roberts <braddr slice-2.puremagic.com> writes:
On Tue, 1 Feb 2011, Walter Bright wrote:

 Bruno Medeiros wrote:
 A more serious issue that I learned (or rather forgotten about before and
 remembered now) is the whole DVCSes keep the whole repository history
 locally aspect, which has important ramifications. If the repository is big,
 although disk space may not be much of an issue,

I still find myself worrying about disk usage, despite being able to get a 2T drive these days for under a hundred bucks. Old patterns of thought die hard.

For what it's worth, the sizes of the key git dirs on my box: dmd.git == 4.4 - 5.9M (depends on if the gc has run recently to re-pack new objects) druntime.git == 1.4 - 3.0M phobos.git == 5.1 - 6.7M The checked out copy of each of those is considerably more than the packed full history. The size, inclusive of full history and the checked out copy, after a make clean: dmd 15M druntime 4M phobos 16M Ie, essentially negligable. Later, Brad
Feb 01 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/22/11, Christopher Nicholson-Sauls <ibisbasenji gmail.com> wrote:
  If it was possible to do the same with OS
 X, I would.  (Anyone know a little trick for that, using VirtualBox?)

No, that is illegal! But you might want to do a google search for *cough* iDeneb *cough* and download vmware player. :p
Jan 22 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-01-05 22:39, bearophile wrote:
 Jacob Carlborg:

 And sometimes Mac OS X is *slightly* ahead of the other OSes, Tango has
 had support for dynamic libraries on Mac OS X using DMD for quite a
 while now. For D2 a patch is just sitting there in bugzilla waiting for
 the last part of it to be commited. I'm really pushing this because
 people seem to forget this.

A quotation from here: http://whatupdave.com/post/1170718843/leaving-net
 Also stop using codeplex its not real open source! Real open source isnt
submitting a patch and waiting/hoping that one day it might be accepted and
merged into the main line.<

Bye, bearophile

So what are you saying here? That I should fork druntime and apply the patches myself? I already have too many projects to handle, I probably can't handle yet another one. -- /Jacob Carlborg
Jan 06 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Jacob Carlborg:

 So what are you saying here? That I should fork druntime and apply the 
 patches myself? I already have too many projects to handle, I probably 
 can't handle yet another one.

See my more recent post for some answer. I think changing how DMD source code is managed (allowing people to create branches, etc) is not going to increase your work load. On the other hand it's going to make D more open source for people that like this and have some free time. Bye, bearophile
Jan 06 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sun, 09 Jan 2011 04:17:21 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Vladimir Panteleev wrote:
  From taking a quick look, I don't see meld's advantage over WinMerge  
 (other than being cross-platform).

Thanks for pointing me at winmerge. I've been looking for one to work on Windows.

Actually, I just noticed that WinMerge doesn't have three-way merge (in all instances when I needed it my SCM launched TortoiseMerge). That's probably a show-stopper for you. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 08 2011
prev sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 19 Jan 2011 13:11:07 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 KennyTM~ wrote:
 You should use LF ending, not CRLF ending.

I never thought of that. Fixing that, it gets further, but still innumerable errors:

If apt-get update doesn't fix it, only an update will - looks like your Ubuntu version is so old, Canonical is no longer maintaining repositories for it. The only alternative is downloading and installing the components manually, and that probably will take half a day :P -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 19 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 08 Jan 2011 17:32:05 +0200, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:

 On 1/8/11, Jacob Carlborg <doob me.com> wrote:
 Ever heard of TortoiseGit: http://code.google.com/p/tortoisegit/

I can't stand Turtoise projects. They install explorer shells and completely slow down the system whenever I'm browsing through the file system. "Turtoise" is a perfect name for it.

Hmm, MSysGit comes with its own shell extension (GitCheetah), although it's just something to integrate the standard GUI tools (git gui / gitk) into the Explorer shell. It's optional, of course (installer option). -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 08 2011
prev sibling parent retard <re tard.com.invalid> writes:
Sat, 22 Jan 2011 00:58:59 -0800, Walter Bright wrote:

 Gour wrote:
 I'm very seriously considering to put PC-BSD on my desktop and of
 several others in order to reduce my admin-time required to maint. all
 those machines.

OSX is the only OS (besides DOS) I've had that had painless upgrades. Windows upgrades never ever work in place (at least not for me). You have to wipe the disk, install from scratch, then reinstall all your apps and reconfigure them. You're hosed if you lose an install disk or the serial # for it. Ubuntu isn't much better, but at least you don't have to worry about install disks and serial numbers. I just keep a list of sudo apt-get commands! That works pretty good until the Ubuntu gods just decide to drop kick your apps (like sunbird) out of the repository.

Don't blame Ubuntu, http://en.wikipedia.org/wiki/Mozilla_Sunbird "It was developed as a standalone version of the Lightning calendar and scheduling extension for Mozilla Thunderbird. Development of Sunbird was ended with release 1.0 beta 1 to focus on development of Mozilla Lightning.[6][7]" Ubuntu doesn't drop support for widely used software. I'd use Google's Calendar instead.
Jan 22 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sun, 09 Jan 2011 02:34:42 +0200, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:

 Now do it on Windows!!
Now that *would* probably take an afternoon.

Done! Just had to install PyGTK. (Luckily for me, meld is written in Python, so there was no need to mess with MinGW :P) From taking a quick look, I don't see meld's advantage over WinMerge (other than being cross-platform). -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 08 2011
prev sibling parent retard <re tard.com.invalid> writes:
Thu, 20 Jan 2011 13:33:58 +0100, Gour wrote:

 On Thu, 20 Jan 2011 06:39:08 -0500
 Jeff Nowakowski <jeff dilacero.org> wrote:
 
 
 No, I haven't tried it. I'm not going to try every OS that comes down
 the pike.

Then please, without any offense, do not give advises about something which you did not try. I did use Ubuntu...
 So instead of giving you a bunch of sane defaults, you have to make a
 bunch of choices up front.

Right. That's why there is no need for separate distro based on DE user wants to have, iow, by simple: pacman -Sy xfce4 you get XFCE environment installed...same wit GNOME & KDE.

It's the same in Ubuntu. You can install the minimal server build and install the DE of your choice in similar way. The prebuilt images (Ubuntu, Kubuntu, Xubuntu, Lubuntu, ...) are for those who can't decide and don't want to fire up a terminal for writing down bash code. In Ubuntu you have even more choice. The huge metapackage or just the DE packages, with or without recommendations. A similar system just doesn't exist for Arch. For the lazy user Ubuntu is a dream come true - you never need to launch xterm if you don't want. There's a GUI for almost everything.
 
 That's a heavy investment of time, especially for somebody unfamiliar
 with Linux.

Again, you're speaking without personal experience...

You're apparently a Linux fan, but have you got any idea which BSD or Solaris distro to choose? The choice isn't as simple if you have zero experience with the system.
 
 Moreover, in TDPL's foreword, Walter speaks about himself as "..of an
 engineer..", so I'm sure he is capable to handle The Arch Way (see
 section Simplicity at https://wiki.archlinux.org/index.php/Arch_Linux)
 which says: "The Arch Way is a philosophy aimed at keeping it simple.

I think Walter's system isn't up to date because he is a lazy bitch. Has all the required competence but never bothers to update if it just works (tm). The same philosophy can be found in dmd/dmc. The code is sometimes hard to read and hard to maintain and buggy, but if it works, why fix it?
 The Arch Linux base system is quite simply the minimal, yet functional
 GNU/Linux environment; the Linux kernel, GNU toolchain, and a handful of
 optional, extra command line utilities like links and Vi. This clean and
 simple starting point provides the foundation for expanding the system
 into whatever the user requires." and from there install one of the
 major DEs (GNOME, KDE or XFCE) to name a few.

I'd give my vote for LFS. It's quite minimal.
 
 The upgrade problems are still there. *Every package* you upgrade has a
 chance to be incompatible with the previous version. The longer you
 wait, the more incompatibilities there will be.

There are no incompatibilities...if I upgrade kernel, it means that package manager will figure out what components has to be updated... Remember: there are no packages 'tagged' for any specific release!

Even if the package manager works perfectly, the repositories have bugs in their dependencies and other metadata.
 
 Highlighting the problem of waiting too long to upgrade. You're
 skipping an entire release. I'd like to see you take a snapshot of Arch
 from 2008, use the system for 2 years without updating, and then
 upgrade to the latest packages. Do you think Arch is going to magically
 have no problems?

I did upgrade on my father-in-law's machine which was more then 1yr old without any problem. You think there must be some magic to handle it...ask some FreeBSD user how they do it. ;)

There's usually a safe upgrade period. If you wait too much, package conflicts will appear. It's simply too much work to keep rules for all possible package transitions. For example libc update breaks kde, but it's now called kde4. The system needs to know how to first remove all kde4 packages and update them. Chromium was previously a game, but now it's a browser, the game becomes chromium-bsu or something. I have hard time believing the minimal Arch does all this.
Jan 20 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:
 Adrian Mercieca:
 
 How does D square up, performance-wise, to C and C++ ? Has anyone got any
 benchmark figures?

DMD has an old back-end, it doesn't use SSE (or AVX) registers yet (64 bit version will use 8 or more SSE registers), and sometimes it's slower for integer programs too.

The benchmarks you posted where it was supposedly slower in integer math turned out to be mistaken.
 I've seen DMD programs slow down if you nest two
 foreach inside each other. There is a collection of different slow
 microbenchmarks.
 
 But LDC1 is able to run D1 code that looks like C about equally fast as C or
 sometimes a bit faster.
 
 DMD2 uses thread local memory on default that in theory slows code down a bit
 if you use global data, but I have never seen a benchmark that shows this
 slowdown clearly (an there is __gshared too, but sometimes it seems a
 placebo).
 
 If you use higher level constructs your program will often go slower.

Rubbish. The higher level constructs are "lowered" into the equivalent low level constructs.
 Often one of the most important things for speed is memory management, D
 encourages to heap allocate a lot (class instances are usually on the heap),
 and this is very bad for performance,

That is not necessarily true. Using the gc can often result in higher performance than explicit allocation, for various subtle reasons. And saying it is "very bad" is just wrong.
 also because the built-in GC doesn't
 have an Eden generation managed as a stack. So if you want more performance
 you must program like in Pascal/Ada, stack-allocating a lot, or using memory
 pools, etc. It's a lot a matter of self-discipline while you program.

This is quite wrong.
Jan 05 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
For people interested in do-it-yourself regarding benchmarking D, there are
some synthetic ones here:
http://is.gd/kbiQM

Many others on request.

Bye,
bearophile
Jan 05 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Long Chang" <changedalone gmail.com> wrote in message 
news:mailman.445.1294291595.4748.digitalmars-d puremagic.com...
 2011/1/6 Walter Bright <newshound2 digitalmars.com>

 bearophile wrote:

 Adrian Mercieca:

  How does D square up, performance-wise, to C and C++ ? Has anyone got 
 any
 benchmark figures?

DMD has an old back-end, it doesn't use SSE (or AVX) registers yet (64 bit version will use 8 or more SSE registers), and sometimes it's slower for integer programs too.

The benchmarks you posted where it was supposedly slower in integer math turned out to be mistaken. I've seen DMD programs slow down if you nest two
 foreach inside each other. There is a collection of different slow
 microbenchmarks.

 But LDC1 is able to run D1 code that looks like C about equally fast as 
 C
 or
 sometimes a bit faster.

 DMD2 uses thread local memory on default that in theory slows code down 
 a
 bit
 if you use global data, but I have never seen a benchmark that shows 
 this
 slowdown clearly (an there is __gshared too, but sometimes it seems a
 placebo).

 If you use higher level constructs your program will often go slower.

Rubbish. The higher level constructs are "lowered" into the equivalent low level constructs. Often one of the most important things for speed is memory management, D
 encourages to heap allocate a lot (class instances are usually on the
 heap),
 and this is very bad for performance,

That is not necessarily true. Using the gc can often result in higher performance than explicit allocation, for various subtle reasons. And saying it is "very bad" is just wrong. also because the built-in GC doesn't
 have an Eden generation managed as a stack. So if you want more
 performance
 you must program like in Pascal/Ada, stack-allocating a lot, or using
 memory
 pools, etc. It's a lot a matter of self-discipline while you program.

This is quite wrong.

I using D for 3 years . I am not in newsgroup because my English is very pool . D is excellent , I try it with Libevent, Libev, pcre, sqlite, c-ares, dwt, and a lot other amazing Lib. It work great with C-lib . I enjoy it so much . My work is a web developer, I also try use D in web field , It not result well . Adam D. Ruppe post some interesting cod in here , And I find a lot people try in web field. for example: (mango, https://github.com/temiy/daedalus, Sendero ... ) , But in the end I had to say, most D project is dying . D like a beautiful girl friends, You play with her can have a lot of fun. But she is be scared to make promisee , you can't count your life on it. she is not a good potential marriage . her life is still in mess, and day after day she is more smart but not become more mature. so if you want do some serious work , You'd better choose another language. if you just wan fun , D is a good companion .

I'd say D is more like an above-average teen. Sure, they're young and naturally may still fuck up now and then, but they're operating on a strong foundation and just need a little more training.
Jan 05 2011
prev sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Fri, 07 Jan 2011 04:31:35 +0200, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:

 On 1/7/11, Vladimir Panteleev <vladimir thecybershadow.net> wrote:
 On Fri, 07 Jan 2011 04:09:04 +0200, Andrej Mitrovic
 <andrej.mitrovich gmail.com> wrote:

 I don't think git really needs MSYS? I mean I've just installed git
 again and it does have it's own executable runnable from the console.

MSysGit comes with its own copy of MSys. It's pretty transparent to the user, though.

Aye, but I didn't download that one, I got the one on the top here: https://code.google.com/p/msysgit/downloads/list?can=3 And if I put git.exe in it's own directory the only .dll it complains about is libiconv2.dll (well that, and some missing templates). Using these two alone seems to work fine.

Ah, that's interesting! Must be a recent change. So they finally rewrote all the remaining bash/perl components to C? If so, that should give it a significant speed boost, most noticeable on Windows. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 07 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/5/11, Nick Sabalausky <a a.a> wrote:
 And Linux is maybe *slightly* ahead of even Windows because, like bearophile
 said, it'll get 64-bit support first..

I wonder if the reason for that is Optlink (iirc it doesn't support 64bit even for DMC, right?).
Jan 05 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 05 Jan 2011 14:53:16 -0500, Walter Bright  
<newshound2 digitalmars.com> wrote:

 bearophile wrote:
 Often one of the most important things for speed is memory management, D
 encourages to heap allocate a lot (class instances are usually on the  
 heap),
 and this is very bad for performance,

That is not necessarily true. Using the gc can often result in higher performance than explicit allocation, for various subtle reasons. And saying it is "very bad" is just wrong.

In practice, it turns out D's GC is pretty bad performance-wise. Avoiding using the heap (or using the C heap) whenever possible usually results in a vast speedup. This is not to say that the GC concept is to blame, I think we just have a GC that is not the best out there. It truly depends on the situation. In something like a user app where the majority of the time is spent sleeping waiting for events, the GC most likely does very well. I expect the situation to get better when someone has time to pay attention to increasing GC performance. -Steve
Jan 05 2011
prev sibling next sibling parent Long Chang <changedalone gmail.com> writes:
--0016e686ce222ed2eb049926be21
Content-Type: text/plain; charset=UTF-8

2011/1/6 Walter Bright <newshound2 digitalmars.com>

 bearophile wrote:

 Adrian Mercieca:

  How does D square up, performance-wise, to C and C++ ? Has anyone got any
 benchmark figures?

DMD has an old back-end, it doesn't use SSE (or AVX) registers yet (64 bit version will use 8 or more SSE registers), and sometimes it's slower for integer programs too.

The benchmarks you posted where it was supposedly slower in integer math turned out to be mistaken. I've seen DMD programs slow down if you nest two
 foreach inside each other. There is a collection of different slow
 microbenchmarks.

 But LDC1 is able to run D1 code that looks like C about equally fast as C
 or
 sometimes a bit faster.

 DMD2 uses thread local memory on default that in theory slows code down a
 bit
 if you use global data, but I have never seen a benchmark that shows this
 slowdown clearly (an there is __gshared too, but sometimes it seems a
 placebo).

 If you use higher level constructs your program will often go slower.

Rubbish. The higher level constructs are "lowered" into the equivalent low level constructs. Often one of the most important things for speed is memory management, D
 encourages to heap allocate a lot (class instances are usually on the
 heap),
 and this is very bad for performance,

That is not necessarily true. Using the gc can often result in higher performance than explicit allocation, for various subtle reasons. And saying it is "very bad" is just wrong. also because the built-in GC doesn't
 have an Eden generation managed as a stack. So if you want more
 performance
 you must program like in Pascal/Ada, stack-allocating a lot, or using
 memory
 pools, etc. It's a lot a matter of self-discipline while you program.

This is quite wrong.

I using D for 3 years . I am not in newsgroup because my English is very pool . D is excellent , I try it with Libevent, Libev, pcre, sqlite, c-ares, dwt, and a lot other amazing Lib. It work great with C-lib . I enjoy it so much . My work is a web developer, I also try use D in web field , It not result well . Adam D. Ruppe post some interesting cod in here , And I find a lot people try in web field. for example: (mango, https://github.com/temiy/daedalus, Sendero ... ) , But in the end I had to say, most D project is dying . D like a beautiful girl friends, You play with her can have a lot of fun. But she is be scared to make promisee , you can't count your life on it. she is not a good potential marriage . her life is still in mess, and day after day she is more smart but not become more mature. so if you want do some serious work , You'd better choose another language. if you just wan fun , D is a good companion . --0016e686ce222ed2eb049926be21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">2011/1/6 Walter Bright <span dir=3D"ltr"=
&lt;<a href=3D"mailto:newshound2 digitalmars.com">newshound2 digitalmars.c=

0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1e= x;"> <div class=3D"im">bearophile wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Adrian Mercieca:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> How does D square up, performance-wise, to C and C++ ? Has anyone got any<b= r> benchmark figures?<br> </blockquote> <br> DMD has an old back-end, it doesn&#39;t use SSE (or AVX) registers yet (64 = bit<br> version will use 8 or more SSE registers), and sometimes it&#39;s slower fo= r<br> integer programs too.<br> </blockquote> <br></div> The benchmarks you posted where it was supposedly slower in integer math tu= rned out to be mistaken.<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> I&#39;ve seen DMD programs slow down if you nest two<br> foreach inside each other. There is a collection of different slow<br> microbenchmarks.<br> <br> But LDC1 is able to run D1 code that looks like C about equally fast as C o= r<br> sometimes a bit faster.<br> <br> DMD2 uses thread local memory on default that in theory slows code down a b= it<br> if you use global data, but I have never seen a benchmark that shows this<b= r> slowdown clearly (an there is __gshared too, but sometimes it seems a<br> placebo).<br> <br> If you use higher level constructs your program will often go slower.<br> </blockquote> <br></div> Rubbish. The higher level constructs are &quot;lowered&quot; into the equiv= alent low level constructs.<div class=3D"im"><br> <br> <br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Often one of the most important things for speed is memory management, D<br=

,<br> and this is very bad for performance,<br> </blockquote> <br></div> That is not necessarily true. Using the gc can often result in higher perfo= rmance than explicit allocation, for various subtle reasons. And saying it = is &quot;very bad&quot; is just wrong.<div class=3D"im"><br> <br> <br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> also because the built-in GC doesn&#39;t<br> have an Eden generation managed as a stack. So if you want more performance= <br> you must program like in Pascal/Ada, stack-allocating a lot, or using memor= y<br> pools, etc. It&#39;s a lot a matter of self-discipline while you program.<b= r> </blockquote> <br></div> This is quite wrong.<br> </blockquote></div><br>I using D for 3 years . I am not in newsgroup becaus= e my English is very pool .<br>D is <span class=3D"enfont">excellent , I tr= y it with Libevent,=C2=A0 Libev,=C2=A0 pcre, sqlite,=C2=A0 c-ares, dwt, and= a lot other amazing Lib. It work great with C-lib .=C2=A0=C2=A0 I enjoy it= so much .<br> My work is a web developer, I also try use D in web field ,=C2=A0 It not re= sult well .<br><br>Adam D. Ruppe post some </span><span class=3D"enfont">in= teresting cod in here , And I find a lot people=C2=A0 try in web field. for= example: (mango, </span><a href=3D"https://github.com/temiy/daedalus">http= s://github.com/temiy/daedalus</a>, Sendero=C2=A0 ... <span class=3D"enfont"=
)=C2=A0=C2=A0 , But in the end I had to say, most D project is dying .<br>

of fun.=C2=A0 But she is be scared to make promisee ,=C2=A0=C2=A0 you can&= #39;t count your life on it. she is not a good </span><span id=3D"result_bo= x" class=3D"short_text" lang=3D"en"><span title=3D"=E7=82=B9=E5=87=BB=E5=8F= =AF=E6=98=BE=E7=A4=BA=E5=85=B6=E4=BB=96=E7=BF=BB=E8=AF=91" class=3D"hps">po= tential</span> <span title=3D"=E7=82=B9=E5=87=BB=E5=8F=AF=E6=98=BE=E7=A4=BA= =E5=85=B6=E4=BB=96=E7=BF=BB=E8=AF=91" class=3D"hps">marriage</span></span> = .=C2=A0 her life is still in mess, and day after day she is more smart but = <span id=3D"result_box" class=3D"short_text" lang=3D"en"><span title=3D"=E7= =82=B9=E5=87=BB=E5=8F=AF=E6=98=BE=E7=A4=BA=E5=85=B6=E4=BB=96=E7=BF=BB=E8=AF= =91" class=3D"hps">not</span> <span title=3D"=E7=82=B9=E5=87=BB=E5=8F=AF=E6= =98=BE=E7=A4=BA=E5=85=B6=E4=BB=96=E7=BF=BB=E8=AF=91" class=3D"hps">become m= ore mature.</span></span>=C2=A0=C2=A0=C2=A0 so if you want do some <span id= =3D"result_box" class=3D"short_text" lang=3D"en"><span title=3D"=E7=82=B9= =E5=87=BB=E5=8F=AF=E6=98=BE=E7=A4=BA=E5=85=B6=E4=BB=96=E7=BF=BB=E8=AF=91" c= lass=3D"hps">serious</span></span> work ,=C2=A0 You&#39;d better choose ano= ther language.=C2=A0 if you just wan fun , D is a good=C2=A0 companion .<br=

--0016e686ce222ed2eb049926be21--
Jan 05 2011
prev sibling next sibling parent Caligo <iteronvexor gmail.com> writes:
--001636c92627ca765b04992a39f9
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 6, 2011 at 12:28 AM, Walter Bright
<newshound2 digitalmars.com>wrote:

 That's pretty much what I'm afraid of, losing my grip on how the whole
 thing works if there are multiple dmd committers.

 Perhaps using a modern SCM like Git might help?  Everyone could have (and

of the managers would then review the changes and pull and merge with the main branch. It works great; just checkout out Rubinius on Github to see what I mean: https://github.com/evanphx/rubinius --001636c92627ca765b04992a39f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Thu, Jan 6, 2011 at 12:28 AM, Walter = Bright <span dir=3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com">= newshound2 digitalmars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gm= ail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(2= 04, 204, 204); padding-left: 1ex;"> <div class=3D"im"><br></div> That&#39;s pretty much what I&#39;m afraid of, losing my grip on how the wh= ole thing works if there are multiple dmd committers.<br> <br> </blockquote></div>Perhaps using a modern SCM like Git might help?=A0 Every= one could have (and should have) commit rights, and they would send pull re= quests.=A0 You or one of the managers would then review the changes and pul= l and merge with the main branch.=A0 It works great; just checkout out Rubi= nius on Github to see what I mean: <a href=3D"https://github.com/evanphx/ru= binius">https://github.com/evanphx/rubinius</a><br> --001636c92627ca765b04992a39f9--
Jan 06 2011
prev sibling next sibling parent Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
2011/1/6 Nick Sabalausky <a a.a>:
 "Caligo" <iteronvexor gmail.com> wrote in message
 news:mailman.451.1294306555.4748.digitalmars-d puremagic.com...
 Perhaps using a modern SCM like Git might help? =C2=A0Everyone could hav=


 should have) commit rights, and they would send pull requests. =C2=A0You=


 of the managers would then review the changes and pull and merge with th=


 main branch. =C2=A0It works great; just checkout out Rubinius on Github =


 what I mean: https://github.com/evanphx/rubinius

I'm not sure I see how that's any different from everyone having "create =

 submit a patch" rights, and then having Walter or one of the managers rev=

 the changes and merge/patch with the main branch.

With the risk of starting yet another VCS-flamewar: It gives the downstream developers an easier option to work on multiple patches in patch-sets. Many non-trivial changes are too big to do in a single step, but requires series of changes. Sure, the downstream hacker could maintain import/conversion to VCS, but with added job, and when Walter or someone else gets to review they are no longer well-annotated patches. It also facilitates a setup where Walter (BDFL? ;) starts to trust some contributors (if he wants to) more than others, for them to work on private branches and submit larger series of patches for each release. Especially, when you detect a showstopper bug that blocks your progress, IMHO, it's easier using a DVCS to maintain a local patch for the needed fix, until upstream includes it. I've often used that strategy both in D-related and other projects just to remain sane and work-around upstream bugs, I just usually have to jump through a some hoops getting the source into DVCS in the first place. I think it was on this list I saw the comparison of VCS:es to the Blub-problem? http://en.wikipedia.org/wiki/Blub#Blub Although, I don't think the current setup have any _serious_ problems, I think there might be slight advantages to gain. OTOH, unless other current key contributors wants to push it, it's probably not worth the cost of change.
Jan 06 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2011-01-06 at 03:35 -0600, Caligo wrote:
[ . . . ]
        =20
 Perhaps using a modern SCM like Git might help?  Everyone could have
 (and should have) commit rights, and they would send pull requests.
 You or one of the managers would then review the changes and pull and
 merge with the main branch.  It works great; just checkout out
 Rubinius on Github to see what I mean:
 https://github.com/evanphx/rubinius

Whilst I concur (massively) that Subversion is no longer the correct tool for collaborative working, especially on FOSS projects, but also for proprietary ones, I am not sure Git is the best choice of tool. Whilst Git appears to have the zeitgeist, Mercurial and Bazaar are actually much easier to work with. Where Git has GitHub, Mercurial has BitBucket, and Bazaar has Launchpad. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 06 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2011-01-06 at 03:10 -0800, Walter Bright wrote:
 Nick Sabalausky wrote:
 "Caligo" <iteronvexor gmail.com> wrote in message=20
 news:mailman.451.1294306555.4748.digitalmars-d puremagic.com...
 On Thu, Jan 6, 2011 at 12:28 AM, Walter Bright
 <newshound2 digitalmars.com>wrote:

 That's pretty much what I'm afraid of, losing my grip on how the whol=




 thing works if there are multiple dmd committers.

 Perhaps using a modern SCM like Git might help?  Everyone could have =




 should have) commit rights, and they would send pull requests.  You or=



 of the managers would then review the changes and pull and merge with =



 main branch.  It works great; just checkout out Rubinius on Github to =



 what I mean: https://github.com/evanphx/rubinius

I'm not sure I see how that's any different from everyone having "creat=


 submit a patch" rights, and then having Walter or one of the managers r=


 the changes and merge/patch with the main branch.

I don't, either.

Pity, because using one of Mercurial, Bazaar or Git instead of Subversion is likely the best and fastest way of getting more quality contributions to review. Although only anecdotal in every case where a team has switched to DVCS from CVCS -- except in the case of closed projects, obviously -- it has opened things up to far more people to provide contributions. Subversion is probably now the single biggest barrier to getting input on system evolution. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 06 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 06 Jan 2011 21:46:47 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 A couple months back, I did propose moving to git on the dmd internals  
 mailing list, and nobody was interested.

Walter, if you do make the move to git (or in generally switch DVCSes), please make it so that the backend is not in the same repository in the frontend. Since the backend has severe redistribution restrictions, the compiler repository can't be simply forked and published. FWIW I'm quite in favor of a switch to git (even better if you choose GitHub, as was discussed in another thread). I had to go through great lengths to set up a private git mirror of the dmd repository, as dsource kept dropping my git-svnimport connections, and it took forever. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 06 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I've ever only used hg (mercurial), but only for some private
repositories. I'll say one thing: it's pretty damn fast considering it
requires Python to work. Also, Joel's tutorial that introduced me to
hg was short and and to the point: http://hginit.com/
Jan 06 2011
parent "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.459.1294356168.4748.digitalmars-d puremagic.com...
 I've ever only used hg (mercurial), but only for some private
 repositories. I'll say one thing: it's pretty damn fast considering it
 requires Python to work. Also, Joel's tutorial that introduced me to
 hg was short and and to the point: http://hginit.com/

I have to comment on this part: "The main way you notice this is that in Subversion, if you go into a subdirectory and commit your changes, it only commits changes in that subdirectory and all directories below it, which potentially means you've forgotten to check something in that lives in some other subdirectory which also changed. Whereas, in Mercurial, all commands always apply to the entire tree. If your code is in c:\code, when you issue the hg commit command, you can be in c:\code or in any subdirectory and it has the same effect." Funny thing about that: After accidentally committing a subdirectory instead of the full project one too many times, I submitted a TortoiseSVN feature request for an option to always commit the full working directory, or at least an option to warn when you're not committing the full working directory. They absolutely lynched me for having such a suggestion.
Jan 08 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Fri, 07 Jan 2011 01:03:42 +0200, Brad Roberts  
<braddr slice-2.puremagic.com> wrote:

   2) walter's workflow meaning that he'll won't use the scm merge
      facilities.  He manually merges everything.

Not sure about Hg, but in Git you can solve this by simply manually specifying the two parent commits. Git doesn't care how you merged the two branches. In fact, you can even do this locally by using grafts. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 06 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 06 Jan 2011 17:42:29 +0200, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 What are the advantages of Mercurial over git? (git does allow multiple  
 branches.)

We've had a discussion in #d (IRC), and the general consensus there seems to be strongly in favor of Git/GitHub. For completeness (there's been a discussion before) here are my arguments: 1) Git has the largest user base - more people will be able to get started hacking on the source immediately. (GitHub compared to DSource below, some of these also apply to Gitorious, Bitbucket, Launchpad) 2) One-click forking - you can easily publish improvements that are easily discoverable to people interested in the project. (This practically guarantees that an open-source project will never hit a dead end, as long as some people are interested in it - both occasional patches and maintained forks are easily discoverable.) 3) UI for pull requests (requests to merge changes in a forked repository upstream), with comments. 4) Inline comments (you can comment on a specific line in a commit/patch). This integrates very nicely with 3) for great code review capabilities. 5) (Unique to GitHub) The network graph allows visualizing all commits in all forks of the project. 6) GitHub is run by a commercial company, and the same infrastructure is used for hosting commercial projects. Therefore, you can expect better uptime and support. GitHub has integrated wiki, issues and downloads (all optional). One thing GitHub doesn't have that DSource has is forums. I think there is no "shame" in leaving DSource for DigitalMars projects, many large open-source projects use GitHub (see GitHub's front page). Some existing D projects on GitHub: https://github.com/languages/D I think Jérôme's observations of Git performance are specific to Windows. Git is expected to be slower on Windows, since it runs on top of cygwin/msys. Here's a study on the Git wiki: https://git.wiki.kernel.org/index.php/GitBenchmarks Google has done a study of Git vs. Mercurial in 2008: http://code.google.com/p/support/wiki/DVCSAnalysis The main disadvantage they found in Git (poor performance over HTTP) doesn't apply to us, and I believe it was addressed in recent versions anyway. Disclaimer: I use Git, and avoid Mercurial if I can mainly because I don't want to learn another VCS. Nevertheless, I tried to be objective above. As I mentioned on IRC, I strongly believe this must be a fully-informed decision, since changing VCSes again is unrealistic once it's done. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 06 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Fri, 07 Jan 2011 03:17:50 +0200, Michel Fortin  
<michel.fortin michelf.com> wrote:

 Easy forking is nice, but it could be a problem in our case. The license  
 for the backend is not open-source enough for someone to republish it  
 (in a separate own repo) without Walter's permission.

I suggested elsewhere in this thread that the two must be separated first. I think it must be done anyway when moving to a DVCS, regardless of the specific one or which hosting site we'd use. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 06 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Fri, 07 Jan 2011 03:30:16 +0200, Nick Sabalausky <a a.a> wrote:

 I'd consider running under MSYS to be a *major* disadvantage. MSYS is  
 barely
 usable garbage (and cygwin is just plain worthless).

Why? MSysGit works great here! I have absolutely no issues with it. It doesn't pollute PATH, either, because by default only one directory with git/gitk is added to PATH. MSysGit can even integrate with PuTTYLink and use your PuTTY SSH sessions (but you can of course also use MSys' OpenSSH). Git GUI and Gitk even run better on Windows in my experience (something weird about Tcl/Tk on Ubuntu). -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 06 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I don't think git really needs MSYS? I mean I've just installed git
again and it does have it's own executable runnable from the console.

It seems to have a gui as well, runnable with "git gui". Pretty cool.
And you can create an icon shotcut to the repo. Sweet.

I'd vote for either the two, although I have to say I do like github a
lot. I didn't know it supported wiki pages though, I haven't seen
anyone use those on a project.
Jan 06 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Fri, 07 Jan 2011 04:09:04 +0200, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:

 I don't think git really needs MSYS? I mean I've just installed git
 again and it does have it's own executable runnable from the console.

MSysGit comes with its own copy of MSys. It's pretty transparent to the user, though. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 06 2011
prev sibling next sibling parent reply Caligo <iteronvexor gmail.com> writes:
--000e0cd2dcec2012ba0499384349
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 6, 2011 at 5:50 AM, Russel Winder <russel russel.org.uk> wrote:

 Whilst I concur (massively) that Subversion is no longer the correct
 tool for collaborative working, especially on FOSS projects, but also
 for proprietary ones, I am not sure Git is the best choice of tool.
 Whilst Git appears to have the zeitgeist, Mercurial and Bazaar are
 actually much easier to work with.  Where Git has GitHub, Mercurial has
 BitBucket, and Bazaar has Launchpad.

 --
 Russel.

 =============================================================================
 Dr Russel Winder      t: +44 20 7585 2200   voip:
 sip:russel.winder ekiga.net <sip%3Arussel.winder ekiga.net>
 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
 London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

BitBucket has copied almost everything from Github, and I don't understand how they've never been sued. http://dev.pocoo.org/~blackbird/github-vs-bitbucket/bitbucket.html Github team has been the innovator here, and they never stop improving the site with new features and bug fixes. It would be nice to support their work by using Github. There is also Gitorious. It only offers free hosting and it is more team orientated than Github, but Github has recently added the "Organization" feature. The interesting thing about Gitorious is that you can run it on your own server. I don't think you can do that with Github. One cool thing about Github that I like is gist: https://gist.github.com/ It's a pastebin, but it uses Git and supports D syntax. People are always sharing snippets on these newsgroups, and it would have been nice if they were gists. I've never used Bazaar, so no comment on that. But, between Git and Mercurial, I vote for Git. --000e0cd2dcec2012ba0499384349 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Thu, Jan 6, 2011 at 5:50 AM, Russel W= inder <span dir=3D"ltr">&lt;<a href=3D"mailto:russel russel.org.uk">russel = russel.org.uk</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st= yle=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204)= ; padding-left: 1ex;"> Whilst I concur (massively) that Subversion is no longer the correct<br> tool for collaborative working, especially on FOSS projects, but also<br> for proprietary ones, I am not sure Git is the best choice of tool.<br> Whilst Git appears to have the zeitgeist, Mercurial and Bazaar are<br> actually much easier to work with. =A0Where Git has GitHub, Mercurial has<b= r> BitBucket, and Bazaar has Launchpad.<br> <font color=3D"#888888"><br> --<br> Russel.<br> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D<br> Dr Russel Winder =A0 =A0 =A0t: +44 20 7585 2200 =A0 voip: <a href=3D"mailto= :sip%3Arussel.winder ekiga.net">sip:russel.winder ekiga.net</a><br> 41 Buckmaster Road =A0 =A0m: +44 7770 465 077 =A0 xmpp: <a href=3D"mailto:r= ussel russel.org.uk">russel russel.org.uk</a><br> London SW11 1EN, UK =A0 w: <a href=3D"http://www.russel.org.uk" target=3D"_= blank">www.russel.org.uk</a> =A0skype: russel_winder<br> </font></blockquote></div><br>BitBucket has copied almost everything from G= ithub, and I don&#39;t understand how they&#39;ve never been sued. <br><br>= <a href=3D"http://dev.pocoo.org/~blackbird/github-vs-bitbucket/bitbucket.ht= ml">http://dev.pocoo.org/~blackbird/github-vs-bitbucket/bitbucket.html</a><= br> <br>Github team has been the innovator here, and they never stop improving = the site with new features and bug fixes.=A0 It would be nice to support th= eir work by using Github.=A0 <br><br>There is also Gitorious.=A0 It only of= fers free hosting and it is more team orientated than Github, but Github ha= s recently added the &quot;Organization&quot; feature. =A0 The interesting = thing about Gitorious is that you can run it on your own server.=A0 I don&#= 39;t think you can do that with Github.<br> <br>One cool thing about Github that I like is gist: <a href=3D"https://gis= t.github.com/">https://gist.github.com/</a>=A0 <br>It&#39;s a pastebin, but= it uses Git and supports D syntax.=A0 People are always sharing snippets o= n these newsgroups, and it would have been nice if they were gists.=A0 <br> <br>I&#39;ve never used Bazaar, so no comment on that.=A0 But, between Git = and Mercurial, I vote for Git.<br><br> --000e0cd2dcec2012ba0499384349--
Jan 06 2011
parent "Nick Sabalausky" <a a.a> writes:
"Caligo" <iteronvexor gmail.com> wrote in message 
news:mailman.461.1294366839.4748.digitalmars-d puremagic.com...
 BitBucket has copied almost everything from Github, and I don't understand
 how they've never been sued.

 http://dev.pocoo.org/~blackbird/github-vs-bitbucket/bitbucket.html

That page looks like the VCS equivalent of taking pictures of sandwiches from two different restaurants and then bitching "Oh my god! What a blatant copy! Look, they both have meat, lettuce and condiments between slices of bread! And they BOTH have the lettuce on top of the meat! What a pathetic case of plagiarism!" Bah.
Jan 06 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/7/11, Vladimir Panteleev <vladimir thecybershadow.net> wrote:
 On Fri, 07 Jan 2011 04:09:04 +0200, Andrej Mitrovic
 <andrej.mitrovich gmail.com> wrote:

 I don't think git really needs MSYS? I mean I've just installed git
 again and it does have it's own executable runnable from the console.

MSysGit comes with its own copy of MSys. It's pretty transparent to the user, though.

Aye, but I didn't download that one, I got the one on the top here: https://code.google.com/p/msysgit/downloads/list?can=3 And if I put git.exe in it's own directory the only .dll it complains about is libiconv2.dll (well that, and some missing templates). Using these two alone seems to work fine.
Jan 06 2011
prev sibling next sibling parent Caligo <iteronvexor gmail.com> writes:
--001636ef046989d87c049939074d
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 6, 2011 at 8:47 PM, Daniel Gibson <metalcaedes gmail.com> wrote:

 Yeah, see also: http://schacon.github.com/bitbucket.html by the same
 author

 When this rant was new I read a page that listed where Github stole their
 ideas and designs (Sourceforce for example), but I can't find it anymore.
 This rant was bullshit, as even the author seems to have accepted.

 I don't understand why people still mirror and link this crap.

hmmm...Interesting! I did not know that, and thanks for the share. There is even a discussion about it on reddit where the author apologizes. I don't understand why he would do such a thing. --001636ef046989d87c049939074d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Thu, Jan 6, 2011 at 8:47 PM, Daniel G= ibson <span dir=3D"ltr">&lt;<a href=3D"mailto:metalcaedes gmail.com">metalc= aedes gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" = style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 20= 4); padding-left: 1ex;"> <br> Yeah, see also: <a href=3D"http://schacon.github.com/bitbucket.html" target= =3D"_blank">http://schacon.github.com/bitbucket.html</a> by the same author= <br> <br> When this rant was new I read a page that listed where Github stole their i= deas and designs (Sourceforce for example), but I can&#39;t find it anymore= .<br> This rant was bullshit, as even the author seems to have accepted.<br> <br> I don&#39;t understand why people still mirror and link this crap.<br> </blockquote></div><br>hmmm...Interesting!=A0 I did not know that, and than= ks for the share.=A0 There is even a discussion about it on reddit where th= e author apologizes.=A0 I don&#39;t understand why he would do such a thing= .<br> <br><br> --001636ef046989d87c049939074d--
Jan 06 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2011-01-06 at 20:20 -0600, Caligo wrote:

< . . . ignoring all the plagiarism rubbish which has been dealt with by
others . . . >

 There is also Gitorious.  It only offers free hosting and it is more
 team orientated than Github, but Github has recently added the
 "Organization" feature.   The interesting thing about Gitorious is
 that you can run it on your own server.  I don't think you can do that
 with Github.

I have never used Gitorious (though I do have an account). My experience is limited to GitHub, BitBucket, GoogleCode, and Launchpad. The crucial difference between GitHub and BitBucket on the one hand and Launchpad on the other is that Launchpad supports teams as well as individuals. GoogleCode enforces teams and doesn't support individuals at all so doesn't really count. Where SourceForge and all the other sit these days is I guess a moot point.=20
 One cool thing about Github that I like is gist:
 https://gist.github.com/ =20
 It's a pastebin, but it uses Git and supports D syntax.  People are
 always sharing snippets on these newsgroups, and it would have been
 nice if they were gists. =20

Personally I have never used these things, nor found a reason to do so.
 I've never used Bazaar, so no comment on that.  But, between Git and
 Mercurial, I vote for Git.

Mercurial and Git are very similar in so many ways, though there are some crucial differences (the index in Git being the most obvious, but for me the most important is remote tracking branches). Bazaar has a completely different core model. Sadly, fashion and tribalism tend to play far too important a role in all discussions of DVCS -- I note no-one has mentioned Darcs or Monotone yet! And recourse to argument about number of projects using a given DVCS are fatuous. What matters is the support for VCS in the tool chain and the workflow. It is undoubtedly the case that Git and Mercurial currently have the most support across the board, though Canonical are trying very hard to make Bazaar a strong player -- sadly they are focusing too much on Ubuntu and not enough on Windows to stay in the game for software developers, no support for Visual Studio. Anecdotal experience seems to indicate that Mercurial has a more average-developer-friendly use model -- though there are some awkward corners. Despite a huge improvement to Git over the last 3 years, it still lags Mercurial on this front. However, worrying about the average developer is more important for companies and proprietary work than it is for FOSS projects -- where the skill set appears to be better than average. All in all it is up to the project lead to make a choice and for everyone else to live with it. I would advise Walter to shift to one of Mercurial or Git, but if he wants to stick with Subversion -- and suffer the tragic inability to sanely work with branches -- that is his choice. As any Git/Mercurial/Bazaar user knows, Git, Mercurial and Bazaar can all be used as Subversion clients. However without creating a proper bridge these clients cannot be used in a DVCS peer group because of the rebasing that is enforced -- at least by Git and Mercurial, Bazaar has a mode of working that avoids the rebasing and so the Subversion repository appears as a peer in the DVCS peer group. Perhaps the interesting models to consider are GoogleCode that chose to support Mercurial and Subversion, and Codehaus that chose to support Git and Subversion (using Gitosis). Of course DSource already support all three. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 07 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2011-01-06 at 15:03 -0800, Brad Roberts wrote:
[ . . . ]
   1) the history of the current source is a mess.
      a) lack of tags for releases
      b) logical merges have all been done as individual commits

Any repository coming to DVCS from CVS or Subversion will have much worse than this :-((( In the end you have to bite the bullet and so "let's do it, and repair stuff later if we have to".=20
   2) walter's workflow meaning that he'll won't use the scm merge
      facilities.  He manually merges everything.

At a guess I would say that this is more an issue that CVS and Subversion have truly outdated ideas about branching and merging. Indeed merging branches in Subversion seems still to be so difficult it makes a shift to DVCS the only way forward.
 None of this is really a problem, it just becomes a lot more visible when=

 using a system that encourages keeping a very clean history and the use o=

 branches and merging.

And no rebasing! At the risk of over-egging the pudding: No organization or project I have knowledge of that made the shift from CVS or Subversion to DVCS (Mercurial, Bazaar, or Git) has ever regretted it. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 07 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2011-01-06 at 11:46 -0800, Walter Bright wrote:

 A couple months back, I did propose moving to git on the dmd internals ma=

 list, and nobody was interested.

That surprises me. Shifting from Subversion to any of Mercurial, Bazaar or Git, is such a huge improvement in tooling. Especially for support of feature branches.
 One thing I like a lot about svn is this:
=20
 http://www.dsource.org/projects/dmd/changeset/291
=20
 where the web view will highlight the revision's changes. Does git or mer=

 do that? The other thing I like a lot about gif is it sends out emails fo=

 checkin.

This is a feature of the renderer not the version control system. This is not Subversion at work, this is Trac at work. As far as I am aware the Subversion, Mercurial, Git and Bazaar backends for Trac all provide this facility.
=20
 One thing I would dearly like is to be able to merge branches using meld.
=20
 http://meld.sourceforge.net/

Why? Mercurial, Bazaar and Git all support a variety of three-way merge tools including meld, but the whole point of branching and merging is that you don't do it manually -- except in Subversion where merging branching remains a problem.=20 With Mercurial, Bazaar and Git, if you accept a changeset from a branch you jsut merge it, e.g. git merge some-feature-branch job done. If you want to amend the changeset before committing to HEAD then create a feature branch, merge the incoming changeset to the feature branch, work on it till satisfied, merge to HEAD. The only time I used meld these days is to process merge conflicts, not to handle merging per se.=20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 07 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2011-01-07 at 00:31 +0200, Vladimir Panteleev wrote:
[ . . . ]
 FWIW I'm quite in favor of a switch to git (even better if you choose =

 GitHub, as was discussed in another thread). I had to go through great =

 lengths to set up a private git mirror of the dmd repository, as dsource =

 kept dropping my git-svnimport connections, and it took forever.

svnimport is for one-off transformation, i.e. for moving from Subversion to Git. Using git-svn is the way to have Git as your Subversion client -- though you have to remember that it always rebases so your repository cannot be a peer in a Git repository group, it is only a Subversion client. The same applies for Mercurial but not for Bazaar, which can treat the Subversion repository in a Bazaar branch poeer group. There are ways of bridging in Git and Mercurial, but it gets painful. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 07 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2011-01-07 at 02:55 +0200, Vladimir Panteleev wrote:
[ . . . ]
 We've had a discussion in #d (IRC), and the general consensus there seems=

 to be strongly in favor of Git/GitHub. For completeness (there's been a =

 discussion before) here are my arguments:

If the active D contributors are mostly in favour of Git then go for it. Personally I would go with Mercurial but a shift to DVCS is way, way more important than which DVCS!
 1) Git has the largest user base - more people will be able to get starte=

 hacking on the source immediately.

As with all statistics, you can prove nigh on any statement. I doubt Git actually has the largest user base, but it does have the zeitgeist. O'Reilly declared Git the winner in the DVCS race three years ago, and all the Linux, Ruby on Rails, etc,. hype is about Git. On the other hand Sun/Oracle, Python, etc., etc. went with Mercurial. Mercurial and Bazaar are a smoother transition from Subversion, which may or may not be an issue.
 (GitHub compared to DSource below, some of these also apply to Gitorious,=

 Bitbucket, Launchpad)
 2) One-click forking - you can easily publish improvements that are easil=

 discoverable to people interested in the project. (This practically =20
 guarantees that an open-source project will never hit a dead end, as long=

 as some people are interested in it - both occasional patches and =20
 maintained forks are easily discoverable.)

I think this is just irrelevant hype. The real issue is not how easy it is to fork a repository, the issue is how easy is it to create changesets, submit changesets for review, merge changesets into Trunk. I guess the question is not about repositories, it is about review tools: Gerrit, Rietveld, etc. (Jokes about Guido's choice of the name Rietveld should be considered pass=C3=A9, if not part of the furniture :-) (cf. http://en.wikipedia.org/wiki/Gerrit_Rietveld)
 3) UI for pull requests (requests to merge changes in a forked repository=

 upstream), with comments.

Launchpad certainly supports this as, I think BitBucket does. It is an important issue.
 4) Inline comments (you can comment on a specific line in a commit/patch)=

 This integrates very nicely with 3) for great code review capabilities.

Better still use a changeset review processing tool rather than just a workflow?
 5) (Unique to GitHub) The network graph allows visualizing all commits in=

 all forks of the project.

Do the Linux folk use this? I doubt it, once you get to a very large number of forks, it will become useless. A fun tool but only for medium size projects. I guess the question is whether D will become huge or stay small?
 6) GitHub is run by a commercial company, and the same infrastructure is =

 used for hosting commercial projects. Therefore, you can expect better =

 uptime and support.

Launchpad and BitBucket are run by commercial companies.
 GitHub has integrated wiki, issues and downloads (all optional). One thin=

 GitHub doesn't have that DSource has is forums.

Launcpad and BitBucket have all the same.
 I think there is no "shame" in leaving DSource for DigitalMars projects, =

 many large open-source projects use GitHub (see GitHub's front page).

Everyone complains about DSource so either change it or move from it.
 Some existing D projects on GitHub: https://github.com/languages/D
=20
 I think J=C3=A9r=C3=B4me's observations of Git performance are specific t=

 Git is expected to be slower on Windows, since it runs on top of =20
 cygwin/msys.
 Here's a study on the Git wiki: =20
 https://git.wiki.kernel.org/index.php/GitBenchmarks
=20
 Google has done a study of Git vs. Mercurial in 2008:
 http://code.google.com/p/support/wiki/DVCSAnalysis
 The main disadvantage they found in Git (poor performance over HTTP) =20
 doesn't apply to us, and I believe it was addressed in recent versions =

 anyway.
=20
 Disclaimer: I use Git, and avoid Mercurial if I can mainly because I don'=

 want to learn another VCS. Nevertheless, I tried to be objective above.
 As I mentioned on IRC, I strongly believe this must be a fully-informed =

 decision, since changing VCSes again is unrealistic once it's done.

I have to disagree that your presentation was objective, but let us leave it aside so as to avoid flame wars or becoming uncivil. In the end there is a technical choice to be made between Git and Mercurial on the one side and Bazaar on the other since the repository/branch model is so different. If the choice is between Git and Mercurial, then it is really down to personally prejudice, tribalism, etc. If the majority of people who are genuinely active in creating changesets want to go with Git, then do it. Having interminable debates on Git vs. Mercurial is the real enemy. NB This is a decision that should be made by the people *genuinely* active in creating code changes -- people like me who are really just D users really do not count in this election. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 07 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2011-01-06 at 11:46 -0800, Walter Bright wrote:
[ . . . ]
 do that? The other thing I like a lot about gif is it sends out emails fo=

 checkin.

Sorry, I forget to answer this question in my previous reply. Mercurial, Bazaar, and Git all have various hooks for the various branch and repository events. Commit emails are trivial in all of them. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 07 2011
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Fri, 07 Jan 2011 08:53:06 +0100, Don wrote:

 Andrei Alexandrescu wrote:
 What are the advantages of Mercurial over git? (git does allow multiple
 branches.)
 
 Andrei

Essentially political and practical rather than technical. Mercurial doesn't have the blatant hostility to Windows that is evident in git. It also doesn't have the blatant hostility to svn (in fact, it tries hard to ease the transition).

I don't think Git's SVN hostility is a problem in practice. AFAIK there are tools (git-svn comes to mind) that can transfer the contents of an SVN repository, with full commit history and all, to a Git repo. Also, it will only have to be done once, so that shouldn't weigh too heavily on the decision.
 Technically, I don't think there's much difference between git and
 Mercurical, compared to how different they are from svn.

Then my vote goes to Git, simply because that's what I'm familiar with. -Lars
Jan 07 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Fri, 07 Jan 2011 12:15:37 +0200, Russel Winder <russel russel.org.uk>  
wrote:

 On Fri, 2011-01-07 at 00:31 +0200, Vladimir Panteleev wrote:
 [ . . . ]
 FWIW I'm quite in favor of a switch to git (even better if you choose
 GitHub, as was discussed in another thread). I had to go through great
 lengths to set up a private git mirror of the dmd repository, as dsource
 kept dropping my git-svnimport connections, and it took forever.

svnimport is for one-off transformation, i.e. for moving from Subversion to Git. Using git-svn is the way to have Git as your Subversion client -- though you have to remember that it always rebases so your repository cannot be a peer in a Git repository group, it is only a Subversion client. The same applies for Mercurial but not for Bazaar, which can treat the Subversion repository in a Bazaar branch poeer group. There are ways of bridging in Git and Mercurial, but it gets painful.

Sorry, I actually meant git-svn, I confused the two. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 07 2011
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Thu, 06 Jan 2011 11:46:47 -0800, Walter Bright wrote:

 Russel Winder wrote:
 Pity, because using one of Mercurial, Bazaar or Git instead of
 Subversion is likely the best and fastest way of getting more quality
 contributions to review.  Although only anecdotal in every case where a
 team has switched to DVCS from CVCS -- except in the case of closed
 projects, obviously -- it has opened things up to far more people to
 provide contributions.  Subversion is probably now the single biggest
 barrier to getting input on system evolution.

A couple months back, I did propose moving to git on the dmd internals mailing list, and nobody was interested.

I proposed the same on the Phobos list in May, but the discussion went nowhere. It seemed the general consensus was that SVN was "good enough". -Lars
Jan 07 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Fri, 07 Jan 2011 20:33:42 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Don wrote:
 Mercurial doesn't have the blatant hostility to Windows that is evident  
 in git. It also doesn't have the blatant hostility to svn (in fact, it  
 tries hard to ease the transition).

I've been using git on a couple small projects, and I find that I have to transfer the files to Linux in order to check them in to git.

Could you please elaborate? A lot of people are using Git on Windows without any problems. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 07 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/7/11, Walter Bright <newshound2 digitalmars.com> wrote:
 No download for Windows from the git site.

There's a big Windows icon on the right: http://git-scm.com/
Jan 07 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I don't recall Walter ever loosing his cool, which is quite an
achievement on this NG.
Jan 07 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Walter,

On Fri, 2011-01-07 at 10:54 -0800, Walter Bright wrote:
 Russel Winder wrote:
 One thing I would dearly like is to be able to merge branches using me=



 http://meld.sourceforge.net/

Why?

Because meld makes it easy to review, selectively merge, and do a bit of =

 all in one go.

Hummm . . . these days that is seen as being counter-productive to having a full and complete record of the evolution of a project. These days it is assumed that a reviewed changeset is committed as is and then further amendments made as a separate follow-up changeset. A core factor here is of attribution and publicity of who did what. By committing reviewed changesets before amending them, the originator of the changeset is noted as the author of the changeset in the history. As I understand the consequences of the above system, you are always shown as the committer of every change -- but I may just have got this wrong, I haven't actually looked at the DMD repository. =20
 Mercurial, Bazaar and Git all support a variety of three-way merge tool=


 including meld, but the whole point of branching and merging is that yo=


 don't do it manually -- except in Subversion where merging branching
 remains a problem.

But I want to do it manually.

Clearly I don't understand your workflow. When I used Subversion, its merge capabilities were effectively none -- and as I understand it, things have not got any better in reality despite all the publicity about new merge support. So handling changesets from branches and elsewhere always had to be a manual activity. Maintaining a truly correct history was effectively impossible. Now with Bazaar, Mercurial and Git, merge is so crucial to the very essence of what these systems do that I cannot conceive of manually merging except to resolve actual conflicts. Branch and merge is so trivially easy in all of Bazaar, Mercurial and Git, that it changes workflows. Reviewing changesets is still a crucially important thing, but merging them should not be part of that process. =20
 With Mercurial, Bazaar and Git, if you accept a changeset from a branch
 you jsut merge it, e.g.
=20
 	git merge some-feature-branch
=20
 job done.  If you want to amend the changeset before committing to HEAD
 then create a feature branch, merge the incoming changeset to the
 feature branch, work on it till satisfied, merge to HEAD.
=20
 The only time I used meld these days is to process merge conflicts, not
 to handle merging per se.=20

I've always been highly suspicious of the auto-detection of a 3 way merge=

I have always been highly suspicious that compilers can optimize my code better than I can ;-) --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 08 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 2011-01-08 at 15:38 +0100, Jacob Carlborg wrote:
 On 2011-01-06 21:12, Michel Fortin wrote:

 Also
 when I want an overview with git I just type gitk on the command line t=


 bring a window where I can browser the graph of forks, merges and
 commits and see the diff for each commit. Here's what gitk looks like:
 <http://michael-prokop.at/blog/img/gitk.png>


gitk uses the Tk widget set which looks hideous -- at least on my Ubuntu and Debian systems. I now use gitg which appears to have the same functionality, but looks almost acceptable. There is also git-gui. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 08 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Git Extensions looks pretty sweet for use on Windows (I haven't tried
it yet though): https://code.google.com/p/gitextensions/
Jan 08 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/8/11, Jacob Carlborg <doob me.com> wrote:
 Ever heard of TortoiseGit: http://code.google.com/p/tortoisegit/

I can't stand Turtoise projects. They install explorer shells and completely slow down the system whenever I'm browsing through the file system. "Turtoise" is a perfect name for it.
Jan 08 2011
parent "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.493.1294500734.4748.digitalmars-d puremagic.com...
 On 1/8/11, Jacob Carlborg <doob me.com> wrote:
 Ever heard of TortoiseGit: http://code.google.com/p/tortoisegit/

I can't stand Turtoise projects. They install explorer shells and completely slow down the system whenever I'm browsing through the file system. "Turtoise" is a perfect name for it.

You need to go into the "Icon Overlays" section of the settings and set up the "Exclude Paths" and "Include Paths" (Exclude everything, ex "C:\*", and then include whatever path or paths you keep all your projects in.) Once I did that (on TortoiseSVN) the speed was perfectly fine, even though my system was nothing more than an old single-core Celeron 1.7 GHz with 1GB RAM (it's back up to 2GB now though :)).
Jan 08 2011
prev sibling next sibling parent Trass3r <un known.com> writes:
 One other random thought: I'd really hate to use a system that didn't  
 have short sequential changeset identifiers. I think Hg does have that,  
 although I don't think all Hg interfaces actually use it, just some.

It's built into Mercurial.
Jan 08 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/8/11, Nick Sabalausky <a a.a> wrote:
 You need to go into the "Icon Overlays" section of the settings and set up
 the "Exclude Paths" and "Include Paths" (Exclude everything, ex "C:\*", and
 then include whatever path or paths you keep all your projects in.)

Ok thanks, I might give it another try.
Jan 08 2011
prev sibling next sibling parent Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
 Funny thing about that: After accidentally committing a subdirectory instead
 of the full project one too many times, I submitted a TortoiseSVN feature
 request for an option to always commit the full working directory, or at
 least an option to warn when you're not committing the full working
 directory. They absolutely lynched me for having such a suggestion.

branching support SVN knows. (Copy directory) I know some people who considers it a feature to always check out entire SVN-repos, including all branches and all tags. Of course, they are the same people who set aside half-days to do the checkout, and considers it a days work to actually merge something back.
Jan 08 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sun, 09 Jan 2011 00:34:19 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Yeah, I could spend an afternoon doing that.

sudo apt-get build-dep meld wget http://ftp.gnome.org/pub/gnome/sources/meld/1.5/meld-1.5.0.tar.bz2 tar jxf meld-1.5.0.tar.bz2 cd meld-1.5.0 make sudo make install You're welcome ;) (Yes, I just tested it on a Ubuntu install, albeit 10.10. No, no ./configure needed. For anyone else who tries this and didn't already have meld, you may need to apt-get install python-gtk2 manually.) -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 08 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/9/11, Vladimir Panteleev <vladimir thecybershadow.net> wrote:
 On Sun, 09 Jan 2011 00:34:19 +0200, Walter Bright
 <newshound2 digitalmars.com> wrote:

 Yeah, I could spend an afternoon doing that.

sudo apt-get build-dep meld wget http://ftp.gnome.org/pub/gnome/sources/meld/1.5/meld-1.5.0.tar.bz2 tar jxf meld-1.5.0.tar.bz2 cd meld-1.5.0 make sudo make install You're welcome ;) (Yes, I just tested it on a Ubuntu install, albeit 10.10. No, no ./configure needed. For anyone else who tries this and didn't already have meld, you may need to apt-get install python-gtk2 manually.) -- Best regards, Vladimir mailto:vladimir thecybershadow.net

Now do it on Windows!! Now that *would* probably take an afternoon.
Jan 08 2011
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sun, 09 Jan 2011 06:00:21 -0600, Christopher Nicholson-Sauls wrote:

 On 01/08/11 20:18, Walter Bright wrote:
 Vladimir Panteleev wrote:
 On Sun, 09 Jan 2011 00:34:19 +0200, Walter Bright
 <newshound2 digitalmars.com> wrote:

 Yeah, I could spend an afternoon doing that.

sudo apt-get build-dep meld wget http://ftp.gnome.org/pub/gnome/sources/meld/1.5/meld-1.5.0.tar.bz2 tar jxf meld-1.5.0.tar.bz2 cd meld-1.5.0 make sudo make install You're welcome ;)


I say you should consider moving away from *Ubuntu and to something more "developer-friendly" such as Gentoo, where the command to install meld is just: emerge meld ...done. And yes, that's an install from source. I just did it myself, and it took right at one minute.

Gentoo really needs a high-end computer to run fast. FWIW, the same meld takes 7 seconds to install on my ubuntu. That includes fetching the package from the internet (1-2 seconds). Probably even faster on Arch.
Jan 10 2011
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 08 Jan 2011 14:34:19 -0800, Walter Bright wrote:

 Michel Fortin wrote:
 I know you had your reasons, but perhaps it's time for you upgrade to a
 more recent version of Ubuntu? That version is what comes with Hardy
 Heron (april 2008).
 <https://launchpad.net/ubuntu/+source/meld>

I know. The last time I upgraded Ubuntu in place it f****d up my system so bad I had to wipe the disk and start all over. It still won't play videos correctly (the previous Ubuntu worked fine), the rhythmbox music player never worked again, it wiped out all my virtual boxes, I had to spend hours googling around trying to figure out how to reconfigure the display driver so the monitor worked again, etc. I learned my lesson! Yes, I'll eventually upgrade, but I'm not looking forward to it.

Ubuntu has a menu entry for "restricted drivers". It provides support for both ATI/AMD (Radeon 8500 or better, appeared in 1998 or 1999!) and NVIDIA cards (Geforce 256 or better, appeared in 1999!) and I think it automatically suggests (a pop-up window) correct drivers in the latest releases right after the first install. Intel chips are automatically supported by the open source drivers. VIA and S3 may or may not work out of the box. I'm just a bit curious to know what GPU you have? If it's some ancient VLB (vesa local bus) or ISA card, I can donate $15 for buying one that uses AGP or PCI Express. Ubuntu doesn't support all video formats out of the box, but the media players and browsers automatically suggest loading missing drivers. At least in the 3 or 4 latest releases. Maybe the problem isn't the encoder, it might be the Linux incompatible web site.
 Or you could download the latest version from meld's website and
 compile it yourself.

Yeah, I could spend an afternoon doing that.

Another one of these jokes? Probably one of the best compiler authors in the whole world uses a whole afternoon doing something (compiling a program) that total Linux noobs do in less than 30 minutes with the help of Google search.
Jan 10 2011
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 08 Jan 2011 12:36:39 -0800, Walter Bright wrote:

 Lutger Blijdestijn wrote:
 Walter Bright wrote:
 
 Looks like meld itself used git as it's repository. I'd be surprised
 if it doesn't work with git. :-)


What version are you on? I'm using 1.3.2 and its supports git and mercurial (also committing from inside meld & stuff, I take it this is what you mean with supporting a vcs).

The one that comes with: sudo apt-get meld 1.1.5.1

One thing came to my mind. Unless you're using Ubuntu 8.04 LTS, your Ubuntu version isn't supported anymore. They might have already removed the package repositories for unsupported versions and that might indeed lead to problems with graphics and video players as you said. The support for desktop 8.04 and 9.10 is also nearing its end (April this year). I'd recommend backing up your /home and installing 10.04 LTS or 10.10 instead.
Jan 10 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/11/11, Walter Bright <newshound2 digitalmars.com> wrote:
 Yeah, I've spent a lot of time googling for solutions to problems with
 Linux.
 You know what? I get pages of results from support forums - every solution
 is
 different and comes with statements like "seems to work", "doesn't work for
 me",
 etc. The advice is clearly from people who do not know what they are doing,
 and
 randomly stab at things, and these are the first page of google results.

That's my biggest problem with Linux. Having technical problems is not the issue, finding the right solution in the sea of forum posts is the problem. When I have a problem with something breaking down on Windows, most of the time a single google search reveals the solution in one of the very first results (it's either on an MSDN page or one of the more popular forums). This probably has to do with the fact that regular users have either XP or Vista/7 installed. So there's really not much searching you have to do. Once someone posts a solution, that's the end of the story (more often than not). I remember a few years ago I got a copy of Ubuntu, and I wanted to disable antialiased fonts (they looked really bad on the screen). So I simply disabled antialised fonts in one of the display property panels, and thought that would be the end of the story. But guess what? Firefox and other applications don't want to follow the OS settings, and they will override your settings and render websites with antialised fonts. So now I had to search for half an hour to find a solution. I finally find a guide where the instructions are to edit the etc/fonts.conf file. So I do that. But antialised fonts were still active. So I spend another 30 minutes looking for more information. Then I run into another website where the instructions are to delete a couple of fonts from the system. OK. I run the command in the terminal, I reset the system, but then on boot x-org crashes. So now I'm left with a blinking cursor on a black background, with no knowledge whatsover of how to fix x-org or reset its settings. Instinctively I run "help" and I get back a list of 100 commands, but I can only read the last 20 and I've no idea how to scroll up to read more. So, hours wasted and a broken Linux system all because I wanted to disable antialiased fonts. But that's just one example. I have plenty more. GRUB failing to install properly, GRUB failing to detect all of my windows installations, and then there's that "wubi" which *does not* work. Of course there are numerous guides on how to fix wubi as well but those fail too. Bleh. I like open-source, Linux - the kernel might be awesome for all I know, but the distributions plain-simple *suck*.
Jan 11 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Google does seem to take into account whatever information it has on
you, which might explain why your own blog is a top result for you.

If I log out of Google and delete my preferences, searching for "D"
won't find anything about the D language in the top results. But if I
log in and search "D" again, the D website will be the top result.
Jan 11 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-01-11 at 11:53 -0800, Walter Bright wrote:
[ . . . ]
 My display is 1920 x 1200. That just seems to cause grief for Ubuntu. Win=

 has no issues at all with it.

My 1900x1200 screen is fine with Ubuntu. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 11 2011
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Wed, 19 Jan 2011 03:11:07 -0800, Walter Bright wrote:

 KennyTM~ wrote:
 You should use LF ending, not CRLF ending.

I never thought of that. Fixing that, it gets further, but still innumerable errors:

 [snip]

I already told you in message digitalmars.d:126586 "..your Ubuntu version isn't supported anymore. They might have already removed the package repositories for unsupported versions and that might indeed lead to problems" It's exactly like using Windows 3.11 now. Totally unsupported. I'd so sad the leader of the D language is so incompetent with open source technologies. If you really want to stick with outdated operating system versions, why don't you install all the "stable" and "important" services on some headless virtual server (on another machine) and update the latest Ubuntu on your main desktop. It's hard to believe making backups of your /home/walter is so hard. That ought to be everything you need to do with desktop Ubuntu..
Jan 19 2011
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Wed, 19 Jan 2011 19:15:54 +0000, retard wrote:

 Wed, 19 Jan 2011 03:11:07 -0800, Walter Bright wrote:
 
 KennyTM~ wrote:
 You should use LF ending, not CRLF ending.

I never thought of that. Fixing that, it gets further, but still innumerable errors: [snip]

I already told you in message digitalmars.d:126586 "..your Ubuntu version isn't supported anymore. They might have already removed the package repositories for unsupported versions and that might indeed lead to problems"

So.. the situation is so bad that you can't install ANY packages anymore. Accidently removing packages can make the system unbootable and those application are gone for good (unless you do a fresh reinstall). My bet is that if it isn't already impossible to upgrade to a new version, when they remove the repositories for the next Ubuntu version, you're completely fucked up.
Jan 19 2011
prev sibling next sibling parent Andrew Wiley <debio264 gmail.com> writes:
--20cf3054a66b2f3518049a470945
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 20, 2011 at 5:39 AM, Jeff Nowakowski <jeff dilacero.org> wrote:

 On 01/20/2011 12:24 AM, Gour wrote:

 Otoh, with Ubuntu, upgrade from 8.10 to 10.10 is always a major
 undertaking (I'm familiar with it since  '99 when I used SuSE and had
 experience with deps hell.)

Highlighting the problem of waiting too long to upgrade. You're skipping an entire release. I'd like to see you take a snapshot of Arch from 2008, use the system for 2 years without updating, and then upgrade to the latest packages. Do you think Arch is going to magically have no problems?

Ironically, I did this a few years back with an Arch box that was setup, then banished to the TV room as a gaming system, then reconnected to the internet about two years later (I didn't have wifi at the time, and I still haven't put a wifi dongle on the box). It updated with no problems and is still operating happily. Now, I was expecting problems, but on the other hand, since *all* packages are in the rolling release model and individual packages contain specific version dependencies, problems are harder to find than you'd think. --20cf3054a66b2f3518049a470945 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Thu, Jan 20, 2011 at 5:39 AM, Jeff Nowakowski= <span dir=3D"ltr">&lt;<a href=3D"mailto:jeff dilacero.org">jeff dilacero.o= rg</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"im">On 01/20/2011 12:24 AM, Gour wrote:</div><div class=3D"im= "> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Otoh, with Ubuntu, upgrade from 8.10 to 10.10 is always a major<br> undertaking (I&#39;m familiar with it since =A0&#39;99 when I used SuSE and= had<br> experience with deps hell.)<br> </blockquote> <br></div> Highlighting the problem of waiting too long to upgrade. You&#39;re skippin= g an entire release. I&#39;d like to see you take a snapshot of Arch from 2= 008, use the system for 2 years without updating, and then upgrade to the l= atest packages. Do you think Arch is going to magically have no problems?<b= r> </blockquote><div><br></div><div>Ironically, I did this a few years back wi= th an Arch box that was setup, then banished to the TV room as a gaming sys= tem, then reconnected to the internet about two years later (I didn&#39;t h= ave wifi at the time, and I still haven&#39;t put a wifi dongle on the box)= . It updated with no problems and is still operating happily.</div> <div>Now, I was expecting problems, but on the other hand, since *all* pack= ages are in the rolling release model and individual packages contain speci= fic version dependencies, problems are harder to find than you&#39;d think.= </div> </div><br> --20cf3054a66b2f3518049a470945--
Jan 20 2011
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Fri, 28 Jan 2011 15:03:24 +0000, Bruno Medeiros wrote:

 
 I know, I know. :)  (I am up-to-date on D.announce, just not on "D" and
 "D.bugs")
 I still wanted to make that point though. First, for retrospection, but
 also because it may still apply to a few other DSource projects (current
 or future ones).

You don't need to read every post here. Reading every bug report is just stupid.. but it's not my problem. It just means that the rest of us have less competition in everyday situations (getting women, work offers, and so on)
Jan 28 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Bleh. I tried to use Git to update some of the doc files, but getting
the thing to work will be a miracle.

git can't find the public keys unless I use msysgit. Great. How
exactly do I cd to D:\ ?

So I try git-gui. Seems to work fine, I clone the forked repo and make
a few changes. I try to commit, it says I have to update first. So I
do that. *Error: crash crash crash*. I try to close the thing, it just
keeps crashing. CTRL+ALT+DEL time..

Okay, I try another GUI package, GitExtensions. I make new
public/private keys and add it to github, I'm about to clone but then
I get this "fatal: The remote end hung up unexpectedly".

I don't know what to say..
Feb 01 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/2/11, Walter Bright <newshound2 digitalmars.com> wrote:
 Andrej Mitrovic wrote:
 I don't know what to say..

Git is a Linux program and will never work right on Windows. The problems you're experiencing are classic ones I find whenever I attempt to use a Linux program that has been "ported" to Windows.

Yeah, I know what you mean. "Use my app on Windows too, it works! But you have to install this Linux simulator first, though". Is this why you've made your own version of make and microemacs for Windows? I honestly can't blame you. :)
Feb 01 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/2/11, Walter Bright <newshound2 digitalmars.com> wrote:

I've noticed you have "Version Control with Git" listed in your list of books. Did you just buy that recently, or were you secretly planning to switch to Git at the instant someone mentioned it? :p
Feb 01 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/2/11, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 On 2/2/11, Walter Bright <newshound2 digitalmars.com> wrote:

...listed in your list...

Crap.. I just made a 2-dimensional book list by accident. My bad.
Feb 01 2011
prev sibling next sibling parent Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
2011/2/4 Bruno Medeiros <brunodomedeiros+spam com.gmail>:
 Well, like I said, my concern about size is not so much disk space, but the
 time to make local copies of the repository, or cloning it from the internet
 (and the associated transfer times), both of which are not neglectable yet.
 My project at work could easily have gone to 1Gb of repo size if in the last
 year or so it has been stored on a DVCS! :S

 I hope this gets addressed at some point. But I fear that the main
 developers of both Git and Mercurial may be too "biased" to experience
 projects which are typically somewhat small in size, in terms of bytes
 (projects that consist almost entirely of source code).
 For example, in UI applications it would be common to store binary data
 (images, sounds, etc.) in the source control. The other case is what I
 mentioned before, wanting to store dependencies together with the project
 (in my case including the javadoc and source code of the dependencies - and
 there's very good reasons to want to do that).

I think the storage/bandwidth requirements of DVCS:s are very often exagerated, especially for text, but also somewhat for blobs. * For text-content, the compression of archives reduces them to, perhaps, 1/5 of their original size? - That means, that unless you completely rewrite a file 5 times during the course of a project, simple per-revision-compression of the file will turn out smaller, than the single uncompressed base-file that subversion transfers and stores. - The delta-compression applied ensures small changes does not count as a "rewrite". * For blobs, the archive-compression may not do as much, and they certainly pose a larger challenge for storing history, but: - AFAIU, at least git delta-compresses even binaries so even changes in them might be slightly reduced (dunno about the others) - I think more and more graphics are today are written in SVG? - I believe, for most projects, audio-files are usually not changed very often, once entered a project? Usually existing samples are simply copied in? * For both binaries and text, and for most projects, the latest revision is usually the largest. (Projects usually grow over time, they don't consistently shrink) I.E. older revisions are, compared to current, much much smaller, making the size of old history smaller compared to the size of current history. Finally, as a test, I tried checking out the last version of druntime from SVN and compare it to git (AFICT, history were preserved in the git-migration), the results were about what I expected. Checking out trunk from SVN, and the whole history from git: SVN: 7.06 seconds, 5,3 MB on disk Git: 2.88 seconds, 3.5 MB on disk Improvement Git/SVN: time reduced by 59%, space reduced by 34%. I did not measure bandwidth, but my guess is it is somewhere between the disk- and time- reductions. Also, if someone has an example of a recently converted repository including some blobs it would make an interesting experiment to repeat. Regards / Ulrik ----- ulrik ulrik ~/p/test> time svn co http://svn.dsource.org/projects/druntime/trunk druntime_svn ... 0.26user 0.21system 0:07.06elapsed 6%CPU (0avgtext+0avgdata 47808maxresident)k 544inputs+11736outputs (3major+3275minor)pagefaults 0swaps ulrik ulrik ~/p/test> du -sh druntime_svn 5,3M druntime_svn ulrik ulrik ~/p/test> time git clone git://github.com/D-Programming-Language/druntime.git druntime_git ... 0.26user 0.06system 0:02.88elapsed 11%CPU (0avgtext+0avgdata 14320maxresident)k 3704inputs+7168outputs (18major+1822minor)pagefaults 0swaps ulrik ulrik ~/p/test> du -sh druntime_git/ 3,5M druntime_git/
Feb 06 2011
prev sibling next sibling parent Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
2011/2/9 Bruno Medeiros <brunodomedeiros+spam com.gmail>:
 It's unlikely you will see converted repositories with a lot of changing
 blob data. DVCS, at the least in the way they work currently, simply kill
 this workflow/organization-pattern.
 I very much suspect this issue will become more important as time goes on -
 a lot of people are still new to DVCS and they still don't realize the full
 implications of that architecture with regards to repo size. Any file you
 commit will add to the repository size *FOREVER*. I'm pretty sure we haven't
 heard the last word on the VCS battle, in that in a few years time people
 are *again* talking about and switching to another VCS :( . Mark these
 words. (The only way this is not going to happen is if Git or Mercurial are
 able to address this issue in a satisfactory way, which I'm not sure is
 possible or easy)

You don't happen to know about any projects of this kind in any other VCS that can be practically tested, do you? Besides, AFAIU this discussion was originally regarding to the D language components, I.E. DMD, druntime and Phobos. Not a lot of binaries here.
Feb 09 2011
prev sibling next sibling parent Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
2011/2/11 Bruno Medeiros <brunodomedeiros+spam com.gmail>:
 On 09/02/2011 23:02, Ulrik Mikaelsson wrote:
 You don't happen to know about any projects of this kind in any other
 VCS that can be practically tested, do you?

You mean a project like that, hosted in Subversion or CVS (so that you can convert it to Git/Mercurial and see how it is in terms of repo size)? I don't know any of the top of my head, except the one in my job, but naturally it is commercial and closed-source so I can't share it. I'm cloning the Mozilla Firefox repo right now, I'm curious how big it is. ( https://developer.mozilla.org/en/Mozilla_Source_Code_%28Mercurial%29) But other than that, what exactly do you want to test? There is no specific thing to test, if you add a binary file (from a format that is already compressed, like zip, jar, jpg, etc.) of size X, you will increase the repo size by X bytes forever. There is no other way around it. (Unless on Git you rewrite the history on the repo, which doubtfully will ever be allowed on central repositories)

I want to test how much overhead the git-version _actually_ is, compared to the SVN-version. Even though the jpg are unlikely to be much more compressible with regular compression, with delta-compression and the fact of growing project-size it might still be interesting to see how much overhead we're talking, and what the performance over network is.
Feb 12 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-02-16 at 14:51 +0000, Bruno Medeiros wrote:
[ . . . ]
 That stuff about DVCS not having a central repository is another thing=

 that is being said a lot, but is only true in a very shallow (and=20
 non-useful) way. Yes, in DVCS there are no more "working copies" as in=

 Subversion, now everyone's working copy is a full fledged=20
 repository/clone that in technical terms is peer of any other repository.
 However, from an organizational point of view in a project, there is=20
 always going to be a "central" repository. The one that actually=20
 represents the product/application/library, where the builds and=20
 releases are made from. (Of course, there could be more than one central=

 repository if there are multiple kinds of releases like=20
 stable/experimental, or forks of the the product, etc.)

Definitely the case. There can only be one repository that represents the official state of a given project. That isn't really the issue in the move from CVCS systems to DVCS systems.
 Maybe the DVCS world likes the term public/shared repository better, but=

 that doesn't make much difference.

In the Bazaar community, and I think increasingly in Mercurial and Git ones, people talk of the "mainline" or "master".=20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 16 2011
prev sibling next sibling parent Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
2011/2/16 Russel Winder <russel russel.org.uk>:
 Definitely the case. =C2=A0There can only be one repository that represen=

 the official state of a given project. =C2=A0That isn't really the issue =

 the move from CVCS systems to DVCS systems.

Many projects are centered around the concept of a centralized project, a "core"-team, and all-around central organisation and planning. Some projects however, I guess the Linux kernel is a prime example, have been quite de-centralized even in their nature for a long time. In the case of KDE, for a centralized example, there is a definite "project version", which is the version currently blessed by the central project team. There is a centralized project planning, including meetings, setting out goals for the coming development. In the case of Linux, it's FAR less obvious. Sure, most people see master torvalds/linux-2.6.git as THE Linux-version. However, there are many other trees interesting to track as well, such as the various distribution-trees which might incorporate many drivers not in mainline, especially for older stability-oriented kernels, RHEL or Debian is probably THE version to care about. You might also be interested in special-environment-kernels, such as non x86-kernels, in which case you're probably more interested in the central repo for that architecture, which is rarely Linuses. Also, IIRC, hard and soft realtime-enthusiasts neither looks at linuses tree first. Above all, in the Linux-kernel, there is not much of "centralised planning". Linus doesn't call to a big planning-meeting quarterly to set up specific milestones for the next kernel release, but in the beginning of each cycle, he is spammed with things already developed independently, scratching someones itch. He then cherry-picks the things that has got good reviews and are interesting for where he wants to go with the kernel. That is not to say that there aren't a lot of coordination and communication, but there isn't a clear centralized authority steering development in the same ways as in many other projects. The bottom line is, many projects, even ones using DVCS, are often centrally organized. However, the Linux kernel is clear evidence it is not the only project model that works.
Feb 16 2011
prev sibling parent Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
2011/2/17 Bruno Medeiros <brunodomedeiros+spam com.gmail>:
 Yeah, that's true. Some projects, the Linux kernel being one of the best
 examples, are more distributed in nature than not, in actual organizational
 terms. But projects like that are (and will remain) in the minority, a
 minority which is probably a very, very small.

develop, if this will be the case in the future too. The Linux kernel, and a few other projects were probably decentralized from start by necessity, filling very different purposes. However, new tools tends to affect models, which might make it a bit more common in the future. In any case, it's an interesting time to do software development.
Feb 18 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Thu, 06 Jan 2011 09:42:29 -0600
 "Andrei" =3D=3D Andrei Alexandrescu wrote:






Andrei> What are the advantages of Mercurial over git? (git does allow Andrei> multiple branches.) It's not as established as Git/Mercurial, but I like a a lot...coming from Sqlite main developer - Fossil (http://fossil-scm.org). Simple command set, very powerful, using sqlite3 back-end for storage, integrated wiki, distributed bug tracker, extra lite for hosting...it'sp ossible to import/export from/to Git's fast-import/export (see http://fossil-scm.org/index.html/doc/trunk/www/inout.wiki). Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Jan 07 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 08 January 2011 10:39:39 Jacob Carlborg wrote:
 On 2011-01-08 16:01, Russel Winder wrote:
 On Sat, 2011-01-08 at 15:38 +0100, Jacob Carlborg wrote:
 On 2011-01-06 21:12, Michel Fortin wrote:

 Also
 when I want an overview with git I just type gitk on the command line
 to bring a window where I can browser the graph of forks, merges and
 commits and see the diff for each commit. Here's what gitk looks like:
 <http://michael-prokop.at/blog/img/gitk.png>


gitk uses the Tk widget set which looks hideous -- at least on my Ubuntu and Debian systems. I now use gitg which appears to have the same functionality, but looks almost acceptable. There is also git-gui.

Doesn't the Tk widget set look hideous on all platforms. I can't understand why both Mercurial and git have chosen to use Tk for the GUI.

Probably because you don't need much installed for them to work. About all you need is X. Now, I'd still rather that they'd picked a decent-looking GUI toolkit and just required it (_most_ people are running full desktop systems with the proper requirements installed and which will install them if a package needs them and they're not installed), but they were probably trying to make it work in pretty minimal environments. - Jonathan M Davis
Jan 08 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 08 January 2011 20:16:05 Walter Bright wrote:
 Jonathan M Davis wrote:
 Of course, I'd have got nuts having an installation as old as yours
 appears to be,

I think it's less than a year old.

Hmm. I thought that someone said that the version you were running was from 2008. But if it's less than a year old, that generally isn't a big deal unless there's a particular package that you really want updated, and there are usually ways to deal with one package. I do quite like the rolling release model though. - Jonathan M Davis
Jan 08 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Sun, 9 Jan 2011 04:15:07 -0800
 "Jonathan" =3D=3D <jmdavisProg gmx.com> wrote:






Jonathan> Personally, I got sick of it and moved on. Currently, I use Jonathan> Arch, which is _way_ more friendly for building non-repo Jonathan> packages yourself or otherwise messing repo packages. You Jonathan> _can_ choose to build from source but don't _have_ to, and Jonathan> you get a rolling release like you effectively get with Jonathan> Gentoo. So, I'm much happier with Arch than I was with Jonathan> Gentoo. +1 (after spending 5yrs with Gentoo...and never looked back) Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Jan 09 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Wed, 19 Jan 2011 19:15:54 +0000 (UTC)
retard <re tard.com.invalid> wrote:

 "..your Ubuntu version isn't supported anymore. They might have
 already removed the package repositories for unsupported versions and
 that might indeed lead to problems"

That's why we wrote it would be better to use some rolling release like Archlinux where distro cannot become so outdated that it's not possible to upgrade easily. Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Jan 19 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Wed, 19 Jan 2011 20:28:43 -0500
Jeff Nowakowski <jeff dilacero.org> wrote:

 "Q) Why would I not want to use Arch?
=20
 A) [...] you do not have the ability/time/desire for a
 'do-ityourself' GNU/Linux distribution"

I've feeling that you just copied the above from FAQ and never actually tried Archlinux. The "do-it-yourself" from the above means that in Arch user is not forced to use specific DE, WM etc., can choose whether he prefers WiCD over NM etc. On the Ubuntu side, there are, afaik, at least 3 distros achieving the same thing (Ubuntu, KUbuntu, XUBuntu) with less flexibility. :-D
 I also don't see how Archlinux protects you from an outdated system.=20
 It's up to you to update your system. The longer you wait, the more=20
 chance incompatibilities creep in.

That's not true...In Arch there is simply no Arch-8.10 or Arch-10.10 which means that whenever you update your system package manager will simply pull all the packages which are required for desired kernel, gcc version etc. I service my father-in-law's machine and he is practically illiterate for computers and often I do not update his system for months knowing well he does not require bleeding edge stuff, so when there is time for the update it is simple: pacman -Syu with some more packages in a queue than on my machine. ;) Otoh, with Ubuntu, upgrade from 8.10 to 10.10 is always a major undertaking (I'm familiar with it since '99 when I used SuSE and had experience with deps hell.) Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Jan 19 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Wed, 19 Jan 2011 21:57:46 -0500
Gary Whatmore <no spam.sp> wrote:

 This is something the Gentoo and Arch fanboys don't get.=20

First of all I spent >5yrs with Gentoo before jumping to Arch and those are really two different beasts. With Arch I practically have zero-admin time after I did my 1st install.
 They don't have any idea how little time a typical Ubuntu user
 spends maintaining the system and installing updates.

Moreover, I spent enough time servicing Ubuntu for new Linux users (refugees from Windows) and upgrading (*)Ubuntu from e.g. 8.10 to 10.10 was never easy and smooth, while with Arch there is no such thing as 'no packages for my version'.
 Another option is to turn on all automatic updates. Everything
 happens in the background. It might ask for a sudo password once in a
 week.

What if automatic update breaks something which happens? With Arch and without automatic update I can always wait few days to be sure that new stuff (e.g. kernel) do not bring some undesired regressions.
 I personally use CentOS for anything stable. I *Was* a huge Gentoo
 fanboy, but the compilation simply takes too much time, and something
 is constantly broken if you enable ~x86 packages.=20

/me nods having experience with ~amd64
 I've also tried Arch. All the cool kids use it, BUT it doesn't automatica=

 any configuration files in /etc and even worse,=20

You can see what new config files are there (*.pacnew) and simple merge with e.g. meld/ediff is something what I'd always prefer than having my conf files automatically overwritten. ;)
 if you enable the "unstable" community repositories, the packages
 won't stay there long in the repository - a few days! The
 replacement policy is nuts. One of the packages was already removed
 from the server before pacman (the package manager) started
 downloading it! Arch is a pure community based distro for hardcore
 enthusiastics. It's fundamentally incompatible with stability.

You gott what you asked for. :-) What you say does not make sense: You speak about Ubuntu's stability and comparing it with using 'unstable' packages in Arch which means you're comparing apples with oranges... Unstable packages (now 'testing') are for devs & geeks, but normal users can have very decent system by using core/extra/community packages only without much hassle. Sincerely, Gour (satisfied with Arch, just offering friendly advice and not caring much what OS people are using as long as it's Linux) --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Jan 19 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday 20 January 2011 03:39:08 Jeff Nowakowski wrote:
 On 01/20/2011 12:24 AM, Gour wrote:
 I've feeling that you just copied the above from FAQ and never
 actually tried Archlinux.

No, I haven't tried it. I'm not going to try every OS that comes down the pike. If the FAQ says that you're going to have to be more of an expert with your system, then I believe it. If it's wrong, then maybe you can push them to update it.
 The "do-it-yourself" from the above means that in Arch user is not
 forced to use specific DE, WM etc., can choose whether he prefers WiCD
 over NM etc.

So instead of giving you a bunch of sane defaults, you have to make a bunch of choices up front. That's a heavy investment of time, especially for somebody unfamiliar with Linux.
 That's not true...In Arch there is simply no Arch-8.10 or Arch-10.10
 which means that whenever you update your system package manager will
 simply pull all the packages which are required for desired kernel,
 gcc version etc.

The upgrade problems are still there. *Every package* you upgrade has a chance to be incompatible with the previous version. The longer you wait, the more incompatibilities there will be.
 Otoh, with Ubuntu, upgrade from 8.10 to 10.10 is always a major
 undertaking (I'm familiar with it since  '99 when I used SuSE and had
 experience with deps hell.)

Highlighting the problem of waiting too long to upgrade. You're skipping an entire release. I'd like to see you take a snapshot of Arch from 2008, use the system for 2 years without updating, and then upgrade to the latest packages. Do you think Arch is going to magically have no problems?

There is no question that Arch takes more to manage than a number of other distros. However, it takes _far_ less than Gentoo. Things generally just work in Arch, whereas you often have to figure out how to fix problems when updating on Gentoo. I wouldn't suggest Arch to a beginner, but I'd be _far_ more likely to suggest it to someone than Gentoo. Arch really doesn't take all that much to maintain, but it does have a higher setup cost than your average distro, and you do have to do some level of manual configuration that I'd expect a more typical distro like OpenSuSE or Ubuntu to take care of for you. So, I'd say that your view of Arch is likely a bit skewed, because you haven't actually used it, but it still definitely isn't a distro where you just stick in the install disk, install it, and then go on your merry way either. - Jonathan M Davis
Jan 20 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Thu, 20 Jan 2011 06:39:08 -0500
Jeff Nowakowski <jeff dilacero.org> wrote:


 No, I haven't tried it. I'm not going to try every OS that comes down=20
 the pike.=20

Then please, without any offense, do not give advises about something which you did not try. I did use Ubuntu...
 So instead of giving you a bunch of sane defaults, you have to make a=20
 bunch of choices up front.=20

Right. That's why there is no need for separate distro based on DE user wants to have, iow, by simple: pacman -Sy xfce4 you get XFCE environment installed...same wit GNOME & KDE.
 That's a heavy investment of time, especially for somebody
 unfamiliar with Linux.

Again, you're speaking without personal experience... Moreover, in TDPL's foreword, Walter speaks about himself as "..of an engineer..", so I'm sure he is capable to handle The Arch Way (see section Simplicity at https://wiki.archlinux.org/index.php/Arch_Linux) which says: "The Arch Way is a philosophy aimed at keeping it simple. The Arch Linux base system is quite simply the minimal, yet functional GNU/Linux environment; the Linux kernel, GNU toolchain, and a handful of optional, extra command line utilities like links and Vi. This clean and simple starting point provides the foundation for expanding the system into whatever the user requires." and from there install one of the major DEs (GNOME, KDE or XFCE) to name a few.
 The upgrade problems are still there. *Every package* you upgrade has
 a chance to be incompatible with the previous version. The longer you=20
 wait, the more incompatibilities there will be.

There are no incompatibilities...if I upgrade kernel, it means that package manager will figure out what components has to be updated... Remember: there are no packages 'tagged' for any specific release!
 Highlighting the problem of waiting too long to upgrade. You're
 skipping an entire release. I'd like to see you take a snapshot of
 Arch from 2008, use the system for 2 years without updating, and then
 upgrade to the latest packages. Do you think Arch is going to
 magically have no problems?

I did upgrade on my father-in-law's machine which was more then 1yr old without any problem. You think there must be some magic to handle it...ask some FreeBSD user how they do it. ;) Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Jan 20 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Thu, 20 Jan 2011 09:19:54 -0500
Jeff Nowakowski <jeff dilacero.org> wrote:

 Please yourself. I quoted from the FAQ from the distribution's main=20
 site. If that's wrong, then Arch has a big public relations problem.

Arch simply does not offer false promises that system will "Just work". Still, I see the number of users has rapidly increased in last year or so...mostly Ubuntu 'refugees'.
 You're talking about somebody who is running a nearly 3 year old
 version of Ubuntu because he had one bad upgrade experience, and is
 probably running software full of security holes. If he can't spend a
 day a year to upgrade his OS, what makes you think he wants to spend
 time on a more demanding distro?

My point is that due to rolling-release nature, distro like Archlinux require less work in the case when one 'forgets' to update OS and has to do 'major upgrade'. It was my experience with both SuSE and Ubuntu.
 And what happens when the kernel, as it often does, changes the way
 it handles things like devices, and expects the administrator to do
 some tweaking to handle the upgrade? What happens when you upgrade X
 and it no longer supports your video chipset? What happens when you
 upgrade something as basic as the DNS library, and it reacts badly
 with your router?

In the above cases, there is no distro which can save you from some admin work...and the problem is that people expect such system where, often, the only admin work is re-install. :-)
 These are real world examples. Arch is not some magic distribution
 that will make upgrade problems go away.

Sure. But upgrade in rolling-release distro is simpler than in Ubuntu-like one.
 Yeah, I know. I also run Debian Testing, which is a "rolling
 release". I'm not some Ubuntu noob.

Heh, I could imagine you like 'bleeding edge' considering you lived with ~x86 and 'unstable' repos. ;) Now we may close this thread...at least, I do not have anything more to say. :-D Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Jan 20 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Fri, 21 Jan 2011 22:35:55 -0800
Walter Bright <newshound2 digitalmars.com> wrote:

Hello Walter,

 I finally did do it, but as a clean install. I found an old 160G
 drive, wiped it, and installed 10.10 on it. (Amusingly, the "About
 Ubuntu" box says it's version 11.04, and /etc/issue says it's 10.10.)

in last few days I did a little research about 'easy-to-admin OS-es' and the result of it is: PC-BSD (http://www.pcbsd.org/) or Ubuntu-like PC-BSD with a GUI installer. The possible advantage is that here OS means kernel+tools which are strictly separated fro the other 'add-on' packages which should guarantee smooth upgrade. Moreover, PC-BSD deploys so called PBI installer which installs every 'add-on' package with complete set of required libs preventing upgrade-breakages. Of course, some more HD space is wasted but this will be resolved in June/July 9.0 release where such add-on packages will use kind of spool of common-libs, but the main OS is still kept intact. I'm very seriously considering to put PC-BSD on my desktop and of several others in order to reduce my admin-time required to maint. all those machines. Finally, there is latest dmd2 available in 'ports' and having you on PC-BSD will make it even better. ;) Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Jan 21 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/22/2011 10:34 AM, Vladimir Panteleev wrote:
 On Sat, 22 Jan 2011 08:35:55 +0200, Walter Bright
 <newshound2 digitalmars.com> wrote:

 The only real problem I've run into (so far) is the sunbird calendar
 has been unceremoniously dumped from Ubuntu. The data file for it is
 in some crappy binary format, so poof, there goes all my calendar data.

Hi Walter, have you seen this yet? It's an article on how to import your calendar data in Lightning, the official Thunderbird calendar extension. I hope it'll help you: http://brizoma.wordpress.com/2010/05/04/sunbird-and-lightning-removed-from-ubuntu-10-04-lucid-lynx/

Yes, lightning seems to have been the successor mozilla project to sunbird (wikipedia would probably tell you more). Denis _________________ vita es estrany spir.wikidot.com
Jan 22 2011
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 2/1/2011 6:17 PM, Andrej Mitrovic wrote:
 Bleh. I tried to use Git to update some of the doc files, but getting
 the thing to work will be a miracle.
 
 git can't find the public keys unless I use msysgit. Great. How
 exactly do I cd to D:\ ?
 
 So I try git-gui. Seems to work fine, I clone the forked repo and make
 a few changes. I try to commit, it says I have to update first. So I
 do that. *Error: crash crash crash*. I try to close the thing, it just
 keeps crashing. CTRL+ALT+DEL time..
 
 Okay, I try another GUI package, GitExtensions. I make new
 public/private keys and add it to github, I'm about to clone but then
 I get this "fatal: The remote end hung up unexpectedly".
 
 I don't know what to say..

I use cygwin for all my windows work (which I try to keep to a minimum). Works just fine in that environment.
Feb 01 2011
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
On 2/1/2011 7:55 PM, Andrej Mitrovic wrote:
 On 2/2/11, Walter Bright <newshound2 digitalmars.com> wrote:
 Andrej Mitrovic wrote:
 I don't know what to say..

Git is a Linux program and will never work right on Windows. The problems you're experiencing are classic ones I find whenever I attempt to use a Linux program that has been "ported" to Windows.

Yeah, I know what you mean. "Use my app on Windows too, it works! But you have to install this Linux simulator first, though". Is this why you've made your own version of make and microemacs for Windows? I honestly can't blame you. :)

Of course, it forms a nice vicious circle. Without users, there's little incentive to fix and chances are there's fewer users reporting bugs. Sounds.. familiar. :)
Feb 01 2011