Nicolai Waniek Wrote:
> You don't need real branches for that, you may even just copy the source files from one directory to another, but having a backend like SVN doing it will save you lots of work to be done (e.g. you could share some source files through all branches when you're certain that they won't get changed).

Unfortunately, because it doesn't keep track of history, SVN is not very good at merging, so that it gives a little more work for the maintenance of several parallel branches, even though it still reduces the work of reporting patches by maybe 80%.

More powerful tools like darcs and mercurial reduce the number of merge conflicts (and therefore manual work) greatly. darcs has a very interesting concept of dependencies between patches that allow to undo a patch easily: i.e it is possible to remove a patch and the SCM will remove all the patches that were dependent on it.

Decentralized SCM like those ones are better suited to open source software than centralized SCM (CVS, SVN, Clearcase...) because one doesn't need to connect to the central server to be able to work. In this model, each developer has a complete local copy of the central repository, so that he can work offline. He only connects to it to synchronize, so this model scales better than the centralized model.

A google tech talk of presentation of mercurial: http://video.google.com/videoplay?docid=-7724296011317502612

(but of course, it's up to Walter to decide what he is up to...)

Walter Bright wrote:
> Lionello Lunesu wrote:
> 
>> Of course, as somebody mentioned, you get into a deadlock if you want to use two libraries but one library only compiles with DMD 1.007 and the other needs 1.011.
> 
> Unfortunately, I feel that makes the libraries unusable with each other.
> 
>> But even then, you can compile with different compilers and just link the stuff together.
> 
> That is courting disaster :-(. I'd try that only as a very last resort.

Hmm. Then nobody should distribute compiled libraries. The -H switch just became obsolete.

Nicolas J., el 15 de abril a las 13:51 me escribiste:
> Nicolai Waniek Wrote:
> > You don't need real branches for that, you may even just copy the source files from one directory to another, but having a backend like SVN doing it will save you lots of work to be done (e.g. you could share some source files through all branches when you're certain that they won't get changed).
> 
> Unfortunately, because it doesn't keep track of history, SVN is not very good at merging, so that it gives a little more work for the maintenance of several parallel branches, even though it still reduces the work of reporting patches by maybe 80%.
> 
> More powerful tools like darcs and mercurial reduce the number of merge conflicts (and therefore manual work) greatly. darcs has a very interesting concept of dependencies between patches that allow to undo a patch easily: i.e it is possible to remove a patch and the SCM will remove all the patches that were dependent on it.
> 
> Decentralized SCM like those ones are better suited to open source software than centralized SCM (CVS, SVN, Clearcase...) because one doesn't need to connect to the central server to be able to work. In this model, each developer has a complete local copy of the central repository, so that he can work offline. He only connects to it to synchronize, so this model scales better than the centralized model.

The problem with darcs it's it doesn't scale very well (because of
implementation issues, they say). I love darcs for small projects, but
(sadly) it's not really suitable for big ones yet.

Another great (distributed) SCM is git, done by Linus Tolvards for
maintaing the Linux kernel (a really big project, as you know, so it
scales by design).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
 .------------------------------------------------------------------------,
  \  GPG: 5F5A8D05 // F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05 /
   '--------------------------------------------------------------------'
Soñé que tenia un caballo
Que me trataba mejor que vos
Tenia tan buena onda con ella
Era mi yegua, mucho mas que vos

Leandro Lucarella wrote:
> Nicolas J., el 15 de abril a las 13:51 me escribiste:
>> Nicolai Waniek Wrote:
>>> You don't need real branches for that, you may even just copy the source files
>>> from one directory to another, but having a backend like SVN doing it will save
>>> you lots of work to be done (e.g. you could share some source files through all
>>> branches when you're certain that they won't get changed).
>> Unfortunately, because it doesn't keep track of history, SVN is not very good at merging, so that it gives a little more work for the maintenance of several parallel branches, even though it still reduces the work of reporting patches by maybe 80%.
>>
>> More powerful tools like darcs and mercurial reduce the number of merge conflicts (and therefore manual work) greatly. darcs has a very interesting concept of dependencies between patches that allow to undo a patch easily: i.e it is possible to remove a patch and the SCM will remove all the patches that were dependent on it.
>>
>> Decentralized SCM like those ones are better suited to open source software than centralized SCM (CVS, SVN, Clearcase...) because one doesn't need to connect to the central server to be able to work. In this model, each developer has a complete local copy of the central repository, so that he can work offline. He only connects to it to synchronize, so this model scales better than the centralized model.
> 
> The problem with darcs it's it doesn't scale very well (because of
> implementation issues, they say). I love darcs for small projects, but
> (sadly) it's not really suitable for big ones yet.
> 
> Another great (distributed) SCM is git, done by Linus Tolvards for
> maintaing the Linux kernel (a really big project, as you know, so it
> scales by design).
> 

Grr.  Why do we have to have *four* credible competitors to svn all the sudden? (Mercurial, Git, Darcs, Monotone)  When SVN came out it was a no brainer.  Better than CVS: check.  Anything else better than CVS and still free?  Nope.  Ok, SVN it is then!  But now we have to deal with *four* credible challengers to SVN.  Can somebody please tell me which three of those projects are destined for the also-ran bucket so I don't have to waste any time learning them?

[Mostly kidding -- choice is great, competition is great.  I just wish there were one that blew the others so totally out of the water that it would be a no-brainer]

:-)

Leandro Lucarella Wrote:

> The problem with darcs it's it doesn't scale very well (because of
> implementation issues, they say). I love darcs for small projects, but
> (sadly) it's not really suitable for big ones yet.
> 
> Another great (distributed) SCM is git, done by Linus Tolvards for
> maintaing the Linux kernel (a really big project, as you know, so it
> scales by design).
> 
> -- 
Yes. And in fact, browsing the darcs repository online (which I suppose is managed by darcs) is a pretty painful experience. http://abridgegame.org/cgi-bin/darcs.cgi/darcs/

git is hardly an option beacuse it is non-portable (it takes advantages of optimizations for the Libux kernel, from what I gather,  so it's not going to be ported soon), and it has some usability issues due to design choices of its author ("renaming files is not important"). I believe mercurial would be a much better option, as it is said to scale very well. And it also has the Clearcase-like merge with history.

Anyway, this is probably not the right moment to continue discussing things like this.

Nicolas J. wrote:
> Leandro Lucarella Wrote:
> 
>> The problem with darcs it's it doesn't scale very well (because of
>> implementation issues, they say). I love darcs for small projects, but
>> (sadly) it's not really suitable for big ones yet.
>>
>> Another great (distributed) SCM is git, done by Linus Tolvards for
>> maintaing the Linux kernel (a really big project, as you know, so it
>> scales by design).
>>
>> -- 
> Yes. And in fact, browsing the darcs repository online (which I suppose is managed by darcs) is a pretty painful experience. http://abridgegame.org/cgi-bin/darcs.cgi/darcs/
> 
> git is hardly an option beacuse it is non-portable (it takes advantages of optimizations for the Libux kernel, from what I gather,  so it's not going to be ported soon), and it has some usability issues due to design choices of its author ("renaming files is not important"). I believe mercurial would be a much better option, as it is said to scale very well. And it also has the Clearcase-like merge with history.
> 
> Anyway, this is probably not the right moment to continue discussing things like this.

That was my impression about git too, but apparently current devs are more interested and open about win32 issues.  Also you can now get a precompiled git for windows via Cygwin whereas before the answer I got was something like "yeh, you should be able to compile it on Windows with cygwin, no prob".

The inkscape devs have pretty much decided to go with Git.  I cried "noooooo" like you, because my experience had been that Git was for Linux and Unix.  Period.  End of story.  But they say it's not so.  And Git is the only SCM to have Google SoC projects, so that seems like it says something about how much they've got their act together.  Plus it does have that whole Linux seal of approval, so it's not going away any time soon.

The UI issues I don't know much about, but I gather that's what 'cogito' is for -- to put a user-friendly svn-like face on git.

Now may not be the best time to discuss it for D, per-se, but I'm tired of not being able to do commits when I'm home or traveling, and I'm ready to switch to one of these fancy distributed thingamajigs.  I just can't tell which one because none of those projects will come right out and say honestly "<Project> -- We're not as good as <X>,<Y>, and <Z>, but we're usable!"

Like the darcs performance thing.  Never heard that before.  But that plus the idea being kooky to begin with (source code control based on "quantum theory" -- uh, yeh, whatever)  sound like good enough reasons to drop it off the list. :-)  Now what about the other two?  :-)  Gaim (now Pidgin) just announced a move to Monotone, and I assume someone looked carefully into that choice.

Here's something that would matter to me -- which one has the best tools for migrating from svn?  Anyone know?

--bb

Russell Lewis wrote:
> So what do you do now?  Do you rewrite your whole project so that you can pick up the new compiler?  Do you find some sort of hackish workaround in your code to avoid the bug?

Or you could try a different compiler all-together :)

What do you do if you'd get a ICE in Visual Studio for example? Trust me, I got plenty, and each time I just kept rewriting and reordering the code until it worked.

L.

janderson wrote:
> Here's a crazy idea.  Why not have all big libraries in some mega test suite.  You would only run this test on -v1 just before you release a new version (because it would take so long with 100 odd projects).  At the very least you could capture all the compile-time errors that way (and possibly runtime too).

I think that dstress is pretty much what you're talking about; the current limitation, of course, is that it focuses on small testcases instead of larger libraries.  It seems like various libraries could be checked in (with unitests built-in) and this used as a good automated test suite.