Straw poll: Which version control system would you like Parrot to use? (Just a straw poll, not a commitment to change anything)

SVN (Current)
30% (8 votes)
CVS
0% (0 votes)
Git
70% (19 votes)
Mercurial
0% (0 votes)
Bazaar
0% (0 votes)
Total votes: 27

For me, any version would

For me, any version would do, as long as it would be for the better. I know these versions will be a big help to parrot. More power to your site!

Thomas

Familiar

I'd vote SVN or Git as I'm pretty familiar with them, and they tend to be in the main repositories of most big linux distributions, I'm not sure about Mercurial or Bazaar.

That said I can't see any easy way of voting! Website in development?

Comment deleted.

I just posted a comment not to long ago about wanting to cast a vote in the straw poll for git. I'm not seeing that comment. Was it deleted?
There was someone else I distinct remember also wanting to know how to cast a vote -- and also wanting to vote for git.

Update wow, it is amazingly lame that you can't see comments signed out and that the prompt is only to `log in to post a comment`.
--
Evan Carroll
me+perl@evancarroll.com

svn

But primarily for selfish reasons: I have to use it for other projects and I'd rather not flip between tools any more than I can help.

Otherwise anything but CVS ...

My vote

I'm not active with parrot, but it interests me. I'm not sure if this poll is open to any registered user or not; but, I registered to vote git. I also can't figure out how to cast a vote formally.
--
Evan Carroll
me+perl@evancarroll.com

svn

svn:
* non-linear global revision numbers
* works via http proxy
* simple and understandable. i still don't grok git

Voting bug (fixed by whiteknight++)

I cannot seem to vote, but if I could, I would vote for Git. Various objections and answers to changing over to git can be found at https://trac.parrot.org/parrot/wiki/GitObjections

Revision required by HLL project

While I greatly prefer Git myself, there is one bit of not-entirely-obvious change that will be required of HLLs. Some projects have a "required Parrot revision", and this is often treated as a minimum revision, to catch API changes or critical bugfixes while still letting developers work on both Parrot and the HLL at the same time.

Unfortunately, the idea of a minimum revision is a little more complex for a DVCS (though actually more correct in the face of branches -- you can actually check ancestry rather than merely relative commit order).

I don't expect it will be difficult for HLLs to make this change, but they will all need to think about it (or we can provide a tiny script that does the magic for them for whatever DVCS we choose).

(Note that "Just tell HLLs to program against the latest release" doesn't fly for a number of reasons. The simplest one is "We're not ready to slow every project down that much".)

Re: Revision ...

FWIW, in Rakudo's case I had already considered this issue when deciding whether to support a move to Git; on balance I think the advantages of Git far outweigh the inconvenience of switching Rakudo to use git-based ancestry checks instead of svn-based revision numbers.

Of course, if Parrot does switch to Git (+1), then Rakudo will quickly prototype some mechanisms to manage Parrot checkouts and other HLLs will be quite welcome to borrow them.

It's entirely reasonable for other HLL developers to disagree on this point and argue that we should therefore stick with SVN. Countering this, it's my understanding that Parrot's policy is to support only official releases for HLL development, so I don't see the "some HLLs are using intermediate SVN revisions" as a strong argument in favor of sticking with SVN. I.e., I think it's a valid point and definitely something to keep in mind, but it's not a significant negative to switching to a different VCS.

Pm

Git :)

See above