Re: PostgreSQL Developer meeting minutes up

Поиск
Список
Период
Сортировка
От Markus Wanner
Тема Re: PostgreSQL Developer meeting minutes up
Дата
Msg-id 20090602171902.391275u3ps123ht2@mail.bluegap.ch
обсуждение исходный текст
Ответ на Re: PostgreSQL Developer meeting minutes up  (Aidan Van Dyk <aidan@highrise.ca>)
Список pgsql-hackers
Hi,

Quoting "Aidan Van Dyk" <aidan@highrise.ca>:
> Sure, and we can all construct example where that move is both right and
> wrong...

Huh? The problem is the file duplication. The move is an action of a
committer - it's neither right nor wrong in this example.

I cannot see any use case for seemingly random files poping up out of
nowhere, just because git doesn't know how to merge two files after a
mv and a merge.

> But the point is that in PostgreSQL, (and that may be mainly
> because we're using CVS), merges *aren't* something that happens.
> Patches are written against HEAD (master) and then back-patched...

..which can (and better is) represented as a merge in git (for the
sake of comfortable automated merging).

> If you want to turn PostgreSQL devellopment on it's head, then we can
> switch this around, so that patches are always done on the oldest
> branch, and fixes always merged "forward"...

I'd consider that good use of tools, yes. However, I realize that this
probably is pipe-dreaming...

> But the fact is, everyone using CVS wants a "linear history"..... All
> they care about is "cvs update...wait...cvs update ... time ... cvs
> update ..."... Everything *was* linear to them.  Any "merge" type things
> certaily wasn't intentional in CVS...

..no, it just wasn't possible in CVS. Switching to git, people soon
want "merge type things". Heck, it's probably *the* reason for
switching to git.

> So much better that it makes the history as useless as CVS... I think
> one of the reasons people are wanting tomove from CVS to git is that it
> makes things *better*...

Yes, especially merging. Please don't cripple that ability just
because CVS once upon a time enforced a linear history.

> The "exact" history will *always* be
> available, right in CVS if people need it.

Agreed. Please note that I mostly talk about a more correct
representation *of history*, as it happened. This has nothing to do
with single commits per file.

> It's a balance...  We're moving because we want *better* tools and
> access, not the same "mess that CVS is".

Agreed. And please cut as many of its burdens of the past, like
linearity. History is not linear and has never been. But I'm stopping
now before getting overly philosophic...

Regards

Markus Wanner


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_migrator and making columns invisible
Следующее
От: Greg Stark
Дата:
Сообщение: Re: PostgreSQL Developer meeting minutes up