[haiku-development] Re: VOTE: Git or Mercurial (hg) as Haiku's new source control tool
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 14 May 2011 15:16:42 +0200 (MEST)
Oliver Tappe<zooey@xxxxxxxxxxxxxxx> wrote:
> > And if so, can it be left out on the command line, too?
> Nope, git needs it in order to determine the exact changeset you mean (since
> in sub-branches there can be two changesets with the same distance).
[...]
> > Because if it has to be part of the arguments, you could just
> > use the hash instead, too, right?
> Sure, it's just that the descriptor has more meaning for humans. You can
> always use the hash for anything.
In this case, while the information of this string is nice as is (we'd just
need a way to specify them in Trac differently than the SVN revisions), I don't
think that using the branch/distance prefix on the command line is needed in
any way.
Brecht Machiels<brecht@xxxxxxxxxxx> wrote:
> [...] IMO, it doesn't make sense to try to hack a
> property of centralized VCSs on a DVCS. It is fundamentally incompatible!
As has been pointed out by many already, it's not incompatible in the way we
intend to use it (with a central repository at the end).
I don't see why this is so hard to understand.
> Just let SVN go and embrace the new technologies.
>
> Tons of open source projects have switched to distributed version control.
> Surely it can't be that bad? If you're afraid of change, there's no reason
> to switch the a DVCS.
Millions of people are using Windows, it can't be that bad?
The new technology is flawed, and much worse than we have right now. Don't be a
fool and embrace it?
This just contains no argument or useful content.
Adrien wrote:
> I don't see why this wouldn't work as well for a DCVS.
Exactly. As Oliver already proved early on, Git could do exactly what we wanted
to do - it's just too slow to consider. But this is not an architectural but an
implementation detail. I would also be in favor of Stippi's suggestion to fix
the tools, but this would involve quite some work, and I don't see this
happening anytime soon.
Luckily, both Niels and Oliver are trying hard to make their preference viable,
and IMHO, both proposed solutions are acceptable alternatives to making
lightweight tags actually lightweight (I would consider the distance count and
the local revision numbering equally useful) :-)
Now we just need a solution to preserve the value of our existing SVN revision
references.
In any case, someone should file a bug in Git's bug tracker that lightweight
tags aren't really that lightweight.
Bye,
Axel.
Other related posts:
