Lalo Martins wrote:
- Poor support for file renaming and moving; this mean merging my pupland
work wouldn't be any bit less painful on hg than cvs. Can't be solved by
extensions.
Well, it would remember the history, which is a step up from cvs, but
indeed it doesn't deal with merging
Lalo Martins wrote:
A few days ago a friend was describing the Australian system to me. He
(she?) probably didn't describe it very precisely, and I probably didn't
understand it perfectly, but it goes more or less like this:
You vote for a number of options in order: your favourite, your
Raphaël Quinet a écrit :
Previous messages mentioned the option to weight the votes. If the
main developers are happy with the outcome of the vote without any
weighting, then it is not an issue anyway. But if the results of the
vote are not so clear, then Mark (and maybe Leaf, Ryo and other
Mark Wedel wrote:
Any selection method is flawed at some level.
Voting probably does make the most sense - but even then, you get some
complications - should the amount of commits a person do also have weight on
the
number of votes?
A person who does 5 commits a week is using the
A quite common way of voting is to let people mark all thing they want.
For example if we have item a,b,c,d and i can
vote a; that mean a has my preference
vote a, b; that mean a and b have my preference over c and d
vote a, b, c; that mean i don't like d
For the delay, i think we can afford a 1
A few days ago a friend was describing the Australian system to me. He
(she?) probably didn't describe it very precisely, and I probably didn't
understand it perfectly, but it goes more or less like this:
You vote for a number of options in order: your favourite, your second
choice, and so on.
Voting probably does make the most sense - but even then, you get some
complications - should the amount of commits a person do also have weight
on the number of votes?
Ha sorry, I was merely talking metaphorically :)
So I'll say another way: if we were to vote, I'd vote for SVN, but I'm
It's been a couple weeks. So doing a quick scoring (using
http://wiki.metalforge.net/doku.php/user:rednaxela:scmtable as the reference):
CVS SVN Hg BZR DARCS
Key Requirements (7)7 7 6¹ 7 6¹
Top Features (6)3 3
Mark Wedel wrote:
Mercurial: If a good hosting service is available, this may be the best
option.
But hosting here is tricky - commits, at current time, seem to need ssh
access
(may change to https in the future).
One note on this, as of Mercurial 0.9.1, you can push via http as
Mark Wedel wrote:
Alex Schultz wrote:
Mark Wedel wrote:
Mercurial: If a good hosting service is available, this may be the best
option.
But hosting here is tricky - commits, at current time, seem to need ssh
access
(may change to https in the future).
One note
Mark Wedel wrote:
It's been a couple weeks. So doing a quick scoring (using
http://wiki.metalforge.net/doku.php/user:rednaxela:scmtable as the reference):
CVS SVN Hg BZR DARCS
Key Requirements (7) 7 7 6¹ 7 6¹
Top Features (6)
Darcs: Has the same lack of hosting as mercurial, and otherwise isn't really
better in any regard, so don't see a very compelling reason to look into
darcs.
alioth.debian.org hosts several projects using darcs and they're quite
happy to host non-debian projects. This has the disadvantage of
On Tue, 22 Aug 2006 10:28:24 +0200, Tchize [EMAIL PROTECTED] wrote:
I did not follow this thread, but am curious on this point on the wiki
page. It's stated 'good branch handling' on CVS and SVN as no. Am sorry
to raise it now, but i have been using branching on CVS at work for a
while and
Raphaël Quinet wrote:
As a GIMP developer, I have been using
CVS branches extensively: we always maintain HEAD together with at
least one stable branche, while several experimental features are
developed in their own branches, such as the recent Google Summer of
Code projects. We also
Raphaël Quinet wrote:
By partial checkout, I mean the ability to check out only a part of a
module. For example, if you are not using your usual computer that has
all the modules checked out and you just want to fix a bug in one map, it
is possible to do a cvs checkout
I would like to bring up another issue regarding the sf.net webspace
and Mercurial. The last time I checked (looking into running a wiki
on it) all scripts run without a sandbox and as the same user. This
creates a large security issue, where it may be possible for someone
else that has access
Andrew Fuchs wrote:
I would like to bring up another issue regarding the sf.net webspace
and Mercurial. The last time I checked (looking into running a wiki
on it) all scripts run without a sandbox and as the same user. This
creates a large security issue, where it may be possible for
Mark Wedel wrote:
If a distributed model is used, this is how I would see local branches in
use:
Agreed on the points you mentioned, just one comment.
I note that in all of these cases, this is basically functionality that CVS
doesn't really support well. I'd have to double check,
Alex Schultz wrote:
Indeed, that is an issue that prevents it from being usable on sf.net,
though I have heard that project space of some other free hosts does
allow this sort of usage, though I am unsure of if the web space
provided is sufficient on those.
Before we put the cart before
On Mon, 14 Aug 2006 15:19:22 -0600, Alex Schultz wrote:
Ok, I just made up a table of the criteria that Mark listed, and a
couple others, for CVS, SVN, Mercurial, Bzr, and Darcs (anyone want any
others on the table?). If anyone has any revisions or wants to add any
other SCMs feel free to make
Raphaël Quinet wrote:
One thing that could be added in the nice to have list is the
support for migrating local branches to another repository. This
would only apply to the systems that support local branches. So the
choices could be Easy, Hard or Not applicable. Or maybe just
Yes, No,
On Tue, 15 Aug 2006 22:39:59 +0800, Lalo Martins [EMAIL PROTECTED] wrote:
On Tue, 15 Aug 2006 11:40:46 +0200, Raphaël Quinet wrote:
One thing that could be added in the nice to have list is the
support for migrating local branches to another repository.
That's easy; all distributed
Raphaël Quinet wrote:
On Tue, 15 Aug 2006 22:39:59 +0800, Lalo Martins [EMAIL PROTECTED] wrote:
On Tue, 15 Aug 2006 11:40:46 +0200, Raphaël Quinet wrote:
One thing that could be added in the nice to have list is the
support for migrating local branches to another repository.
If a distributed model is used, this is how I would see local branches in use:
- Mirrors of the official repository - could be for speed reasons (one in
europe, one in asia, or just in general to cover outages if the official
repository is down).
- For developers to make their changes
Ok, I just made up a table of the criteria that Mark listed, and a
couple others, for CVS, SVN, Mercurial, Bzr, and Darcs (anyone want any
others on the table?). If anyone has any revisions or wants to add any
other SCMs feel free to make them.
Currently storing it in my namespace on the wiki at:
Alex Schultz wrote:
Ok, I just made up a table of the criteria that Mark listed, and a
couple others, for CVS, SVN, Mercurial, Bzr, and Darcs (anyone want any
others on the table?). If anyone has any revisions or wants to add any
other SCMs feel free to make them.
Currently storing it in my
Mark Wedel wrote:
Alex Schultz wrote:
Ok, I just made up a table of the criteria that Mark listed, and a
couple others, for CVS, SVN, Mercurial, Bzr, and Darcs (anyone want any
others on the table?). If anyone has any revisions or wants to add any
other SCMs feel free to make them.
The recent discussion on the release cycle lead to another conversation about
what source code system could be used.
There seemed to be a lot of opinions on what should be used without any real
clear test to see what is needed. I think a better way would be to define what
crossfire needs
Mark Wedel wrote:
Key requirements (if it doesn't meet these, not usuable - probably everything
out there does)
---
- Network based access (checkouts and commits - shouldn't be a need to log in
to
a specific host to do a commit)
Well, some/most distributed SCMs technically
On Sat, 12 Aug 2006 03:13:14 -0600, Alex Schultz wrote:
Mark Wedel wrote:
Key requirements (if it doesn't meet these, not usuable - probably
everything
out there does)
It looks complete to me, at least it has everything *I* want :-)
Maybe I should make a point here I made on IRC, for the
I should add that I'm not saying we should use bzr; I'll just play the
part of its advocate in the evaluation process, because it's the one I
know the most about (I use it on a daily basis). Personally I'm a bit put
off about it right now due to speed issues, let's see if 0.9 is better.
On Sat,
On Sat, 12 Aug 2006 18:59:55 +0800, Lalo Martins wrote:
On Sat, 12 Aug 2006 03:13:14 -0600, Alex Schultz wrote:
I know bzr used to be really slow but apparently has been improved alot,
however I have heard it is not bandwidth efficent still.
They released 0.9 which is supposedly much faster
32 matches
Mail list logo
