git vs mercurial (было "vcs vs vcs")

Сообщение **t.t** » 20.04.2010 08:29

Для повседневной работы встроенной справки более чем достаточно. А для более глубокого понимания я в принципе больше люблю читать книги, чем маны. Поэтому в этом смысле схема документации mercurial меня устраивает гораздо больше.

Сообщение **t.t** » 20.04.2010 08:57

Позволю себе привести ссылку на ещё одно мнение о субъективности выбора: The Real Difference Between Mercurial and Git.

20.04.2010 09:46

In Mercurial, branching is simpler, as you don’t need to do anything special. You simply clone the repository and start working. When you’re done, you (or someone else) pulls-and-merges.

Погодите, т.е. получается, что в Mercurial на самом деле нет бранчей?

In Git, the process is not so simple but it is more flexible.

Я бы сказал, что это чушь. Сценарий clone/pull доступен и в Git, просто он не называется бранчем. Помимо этого, есть то, что в Git называется бранчем и работает в рамках одной working directory, что в большинстве случаев удобно, а когда неудобно, есть clone/pull.

20.04.2010 09:51

Despite everything I said above about Mercurial branches being anonymous, in Mercurial there are also named branches. However, they are a different concept. In Mercurial, the name of the branch is stored with each commit. This means that branches cannot be deleted as they are in Git

Ага, всё-таки есть, но совсем другое. И совсем уж ужасно, что branch'и перманентны.

Сообщение **t.t** » 20.04.2010 10:57

watashiwa_daredeska писал(а): ↑
20.04.2010 09:51
Despite everything I said above about Mercurial branches being anonymous, in Mercurial there are also named branches. However, they are a different concept. In Mercurial, the name of the branch is stored with each commit. This means that branches cannot be deleted as they are in Git
Ага, всё-таки есть, но совсем другое. И совсем уж ужасно, что branch'и перманентны.

Во-первых, перманентны (были) не ветки, а имена веток. Во-вторых, это в прошлом: начиная с 1.4 есть соответствующее расширение (изменение и удаление имён веток), а с 1.5, говорят (сам пока не смотрел), уже в базовом функционале. В-третьих, и раньше это можно было обойти путём ответвления от именованной ветки с последующим слиянием. Ну и главное -- есть и безымянные ветви. Я сам думал раньше, что переименование веток мне нужно; но с тех пор как узнал, что оно есть, даже не захотелось взглянуть.

Мне в целом реализация ветвей в mercurial нравится даже не то что гораздо больше, чем в git -- мне она в принципе нравится, а гитовская нет.

Сообщение **t.t** » 20.04.2010 11:02

Мне кажется, ты в принципе неправильно понял, как обстоят дела с ветками. Объяснять это долго и сложно, лучше показать. Доберусь до ноута -- набросаю небольшой пример (на кпк у меня меркуриала нет, как понимаешь).

Сообщение **t.t** » 20.04.2010 12:38

t.t писал(а): ↑
20.04.2010 11:02
Мне кажется, ты в принципе неправильно понял, как обстоят дела с ветками. Объяснять это долго и сложно, лучше показать.

Получилось немного длинно, но, надеюсь, внятно:

Shell

t:~/tmp$ hg init 1; cd 1
t:~/tmp/1$ echo 1 >file
t:~/tmp/1$ hg add
adding file
t:~/tmp/1$ hg ci -m init
t:~/tmp/1$ hg branch test
marked working directory as branch test
t:~/tmp/1$ hg ci -m "new branch"
t:~/tmp/1$ echo 2 >>file
t:~/tmp/1$ hg ci -m second
t:~/tmp/1$ hg branches
test                           2:965c482ee779
default                        0:0c0574243706 (inactive)
t:~/tmp/1$ hg glog | egrep -v '(user|date):'
@  changeset:   2:965c482ee779
|  branch:      test
|  tag:         tip
|  summary:     second
|
o  changeset:   1:8947960aca13
|  branch:      test
|  summary:     new branch
|
o  changeset:   0:0c0574243706
   summary:     init
t:~/tmp/1$ hg up default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
t:~/tmp/1$ echo 3 >>file
t:~/tmp/1$ hg ci -m third
created new head
t:~/tmp/1$ hg glog | egrep -v '(user|date):'
@  changeset:   3:0248501b0904
|  tag:         tip
|  parent:      0:0c0574243706
|  summary:     third
|
| o  changeset:   2:965c482ee779
| |  branch:      test
| |  summary:     second
| |
| o  changeset:   1:8947960aca13
|/   branch:      test
|    summary:     new branch
|
o  changeset:   0:0c0574243706
   summary:     init
t:~/tmp/1$ hg branch devel
marked working directory as branch devel
t:~/tmp/1$ echo 4 >>file
t:~/tmp/1$ hg ci -m fourth
t:~/tmp/1$ hg up default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
t:~/tmp/1$ echo 5 >>file
t:~/tmp/1$ hg ci -m fifth
created new head
t:~/tmp/1$ hg glog | egrep -v '(user|date):'
@  changeset:   5:effd16e9035c
|  tag:         tip
|  parent:      3:0248501b0904
|  summary:     fifth
|
| o  changeset:   4:6a946512cf5a
|/   branch:      devel
|    summary:     fourth
|
o  changeset:   3:0248501b0904
|  parent:      0:0c0574243706
|  summary:     third
|
| o  changeset:   2:965c482ee779
| |  branch:      test
| |  summary:     second
| |
| o  changeset:   1:8947960aca13
|/   branch:      test
|    summary:     new branch
|
o  changeset:   0:0c0574243706
   summary:     init
t:~/tmp/1$ hg up devel
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
t:~/tmp/1$ echo 6 >>file
t:~/tmp/1$ hg branch release
marked working directory as branch release
t:~/tmp/1$ hg ci -m sixth
t:~/tmp/1$ hg up default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
t:~/tmp/1$ echo 7 >>file
t:~/tmp/1$ hg ci -m seventh
t:~/tmp/1$ hg up devel
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
t:~/tmp/1$ echo 8 >>file
t:~/tmp/1$ hg ci -m eight
created new head
t:~/tmp/1$ hg glog | egrep -v '(user|date):'
@  changeset:   8:f32d007f449f
|  branch:      devel
|  tag:         tip
|  parent:      4:6a946512cf5a
|  summary:     eight
|
| o  changeset:   7:211b4eb6c4b3
| |  parent:      5:effd16e9035c
| |  summary:     seventh
| |
+---o  changeset:   6:732412dc4b4e
| |    branch:      release
| |    parent:      4:6a946512cf5a
| |    summary:     sixth
| |
| o  changeset:   5:effd16e9035c
| |  parent:      3:0248501b0904
| |  summary:     fifth
| |
o |  changeset:   4:6a946512cf5a
|/   branch:      devel
|
|    summary:     fourth
|
o  changeset:   3:0248501b0904
|  parent:      0:0c0574243706
|  summary:     third
|
| o  changeset:   2:965c482ee779
| |  branch:      test
| |  summary:     second
| |
| o  changeset:   1:8947960aca13
|/   branch:      test
|    summary:     new branch
|
o  changeset:   0:0c0574243706
   summary:     init
t:~/tmp/1$ hg merge test
merging file
warning: conflicts during merge.
merging file failed!
0 files updated, 0 files merged, 0 files removed, 1 files unresolved
There are unresolved merges, you can redo the full merge using:
  hg update -C 8
  hg merge 2
t:~/tmp/1$ nano file
t:~/tmp/1$ hg merge test
abort: outstanding uncommitted merges
t:~/tmp/1$ hg ci -m merge
t:~/tmp/1$ hg glog | egrep -v '(user|date):'
@    changeset:   9:0e792c0b419a
|\   branch:      devel
| |  tag:         tip
| |  parent:      8:f32d007f449f
| |  parent:      2:965c482ee779
| |  summary:     merge
| |
| o  changeset:   8:f32d007f449f
| |  branch:      devel
| |  parent:      4:6a946512cf5a
| |  summary:     eight
| |
| | o  changeset:   7:211b4eb6c4b3
| | |  parent:      5:effd16e9035c
| | |  summary:     seventh
| | |
| +---o  changeset:   6:732412dc4b4e
| | |    branch:      release
| | |    parent:      4:6a946512cf5a
| | |    summary:     sixth
| | |
| | o  changeset:   5:effd16e9035c
| | |  parent:      3:0248501b0904
| | |  summary:     fifth
| | |
| o |  changeset:   4:6a946512cf5a
| |/   branch:      devel
| |    summary:     fourth
| |
| o  changeset:   3:0248501b0904
| |  parent:      0:0c0574243706
| |  summary:     third
| |
o |  changeset:   2:965c482ee779
| |  branch:      test
| |  summary:     second
| |
o |  changeset:   1:8947960aca13
|/   branch:      test
|    summary:     new branch
|
o  changeset:   0:0c0574243706
   summary:     init
t:~/tmp/1$ hg up release
abort: crosses named branches (use 'hg update -C' to discard changes)
t:~/tmp/1$ hg revert file
t:~/tmp/1$ hg up release
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
t:~/tmp/1$ hg merge default
merging file
warning: conflicts during merge.
merging file failed!
0 files updated, 0 files merged, 0 files removed, 1 files unresolved
There are unresolved merges, you can redo the full merge using:
  hg update -C 6
  hg merge 7
t:~/tmp/1$ hg glog | egrep -v '(user|date):'
o    changeset:   9:0e792c0b419a
|\   branch:      devel
| |  tag:         tip
| |  parent:      8:f32d007f449f
| |  parent:      2:965c482ee779
| |  summary:     merge
| |
| o  changeset:   8:f32d007f449f
| |  branch:      devel
| |  parent:      4:6a946512cf5a
| |  summary:     eight
| |
| | @  changeset:   7:211b4eb6c4b3
| | |  parent:      5:effd16e9035c
| | |  summary:     seventh
| | |
| +---@  changeset:   6:732412dc4b4e
| | |    branch:      release
| | |    parent:      4:6a946512cf5a
| | |    summary:     sixth
| | |
| | o  changeset:   5:effd16e9035c
| | |  parent:      3:0248501b0904
| | |  summary:     fifth
| | |
| o |  changeset:   4:6a946512cf5a
| |/   branch:      devel
| |    summary:     fourth
| |
| o  changeset:   3:0248501b0904
| |  parent:      0:0c0574243706
| |  summary:     third
| |
o |  changeset:   2:965c482ee779
| |  branch:      test
| |  summary:     second
| |
o |  changeset:   1:8947960aca13
|/   branch:      test
|    summary:     new branch
|
o  changeset:   0:0c0574243706
   summary:     init
t:~/tmp/1$ nano file
t:~/tmp/1$ hg ci -m "second merge"
t:~/tmp/1$ hg glog | egrep -v '(user|date):'
@    changeset:   10:0105d3d230b0
|\   branch:      release
| |  tag:         tip
| |  parent:      6:732412dc4b4e
| |  parent:      7:211b4eb6c4b3
| |  summary:     second merge
| |
| | o    changeset:   9:0e792c0b419a
| | |\   branch:      devel
| | | |  parent:      8:f32d007f449f
| | | |  parent:      2:965c482ee779
| | | |  summary:     merge
| | | |
| | | o  changeset:   8:f32d007f449f
| | | |  branch:      devel
| | | |  parent:      4:6a946512cf5a
| | | |  summary:     eight
| | | |
| o | |  changeset:   7:211b4eb6c4b3
| | | |  parent:      5:effd16e9035c
| | | |  summary:     seventh
| | | |
o-----+  changeset:   6:732412dc4b4e
  | | |  branch:      release
 / / /   parent:      4:6a946512cf5a
| | |    summary:     sixth
| | |
o | |  changeset:   5:effd16e9035c
| | |  parent:      3:0248501b0904
| | |  summary:     fifth
| | |
+---o  changeset:   4:6a946512cf5a
| |    branch:      devel
| |    summary:     fourth
| |
o |  changeset:   3:0248501b0904
| |  parent:      0:0c0574243706
| |  summary:     third
| |
| o  changeset:   2:965c482ee779
| |  branch:      test
| |  summary:     second
| |
| o  changeset:   1:8947960aca13
|/   branch:      test
|    summary:     new branch
|
o  changeset:   0:0c0574243706
   summary:     init

Сообщение **t.t** » 20.04.2010 13:43

Это пример именованных веток. А насчёт клона и пуша там писалось в качестве примера безымянных веток. Приведу практический пример:

Shell

t:~/tmp$ hg init 1; cd 1
t:~/tmp/1$ echo 1 >file
t:~/tmp/1$ hg add
adding file
t:~/tmp/1$ hg ci -m first
t:~/tmp/1$ hg clone . ../2
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
t:~/tmp/1$ echo 2 >>file
t:~/tmp/1$ hg ci -m second
t:~/tmp/1$ cd ../2
t:~/tmp/2$ echo 2 >file2
t:~/tmp/2$ hg add
adding file2
t:~/tmp/2$ hg ci -m "two files"
t:~/tmp/2$ hg pull
pulling from /home/t/tmp/1
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
t:~/tmp/2$ hg glog | egrep -v '^[| ]*(user|date):'
o  changeset:   2:b226e84439a9
|  tag:         tip
|  parent:      0:b100f0270c1c
|  summary:     second
|
| @  changeset:   1:c725ec3c67a1
|/   user:        Tikhon Tarnavski
|    summary:     two files
|
o  changeset:   0:b100f0270c1c
   summary:     first
t:~/tmp/2$ hg clone . ../3
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
t:~/tmp/2$ echo 3 >>file2
t:~/tmp/2$ hg ci -m "two files 2"
t:~/tmp/2$ cd ../3
t:~/tmp/3$ echo 3 >file3
t:~/tmp/3$ hg add
adding file3
t:~/tmp/3$ hg ci -m "three files"
t:~/tmp/3$ hg pull
pulling from /home/t/tmp/2
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
t:~/tmp/3$ hg glog | egrep -v '^[| ]*(user|date):'
o  changeset:   4:069c703cd6d4
|  tag:         tip
|  parent:      1:c725ec3c67a1
|  summary:     two files 2
|
| @  changeset:   3:e03b50382322
| |  summary:     three files
| |
| o  changeset:   2:b226e84439a9
| |  parent:      0:b100f0270c1c
| |  summary:     second
| |
o |  changeset:   1:c725ec3c67a1
|/   user:        Tikhon Tarnavski
|    summary:     two files
|
o  changeset:   0:b100f0270c1c
   summary:     first
t:~/tmp/3$ hg merge
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
t:~/tmp/3$ hg ci -m merge
t:~/tmp/3$ hg glog | egrep -v '^[| ]*(user|date):'
@    changeset:   5:25210fe63cbf
|\   tag:         tip
| |  parent:      3:e03b50382322
| |  parent:      4:069c703cd6d4
| |  summary:     merge
| |
| o  changeset:   4:069c703cd6d4
| |  parent:      1:c725ec3c67a1
| |  summary:     two files 2
| |
o |  changeset:   3:e03b50382322
| |  summary:     three files
| |
o |  changeset:   2:b226e84439a9
| |  parent:      0:b100f0270c1c
| |  summary:     second
| |
| o  changeset:   1:c725ec3c67a1
|/   user:        Tikhon Tarnavski
|    summary:     two files
|
o  changeset:   0:b100f0270c1c
   summary:     first
t:~/tmp/3$ cd ../2
t:~/tmp/2$ hg merge
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
t:~/tmp/2$ hg ci -m merge
t:~/tmp/2$ hg clone . ../4; cd ../4
updating working directory
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
t:~/tmp/4$ hg pull ../3
pulling from ../3
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 1 changes to 1 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
t:~/tmp/4$ hg glog | egrep -v '^[| ]*(user|date):'
o    changeset:   6:25210fe63cbf
|\   tag:         tip
| |  parent:      5:e03b50382322
| |  parent:      3:069c703cd6d4
| |  summary:     merge
| |
| o  changeset:   5:e03b50382322
| |  parent:      2:b226e84439a9
| |  summary:     three files
| |
+---@  changeset:   4:185f1eceafef
| |/   parent:      3:069c703cd6d4
| |    parent:      2:b226e84439a9
| |    summary:     merge
| |
o |  changeset:   3:069c703cd6d4
| |  parent:      1:c725ec3c67a1
| |  summary:     two files 2
| |
| o  changeset:   2:b226e84439a9
| |  parent:      0:b100f0270c1c
| |  summary:     second
| |
o |  changeset:   1:c725ec3c67a1
|/   user:        Tikhon Tarnavski
|    summary:     two files
|
o  changeset:   0:b100f0270c1c
   summary:     first
t:~/tmp/4$ hg merge
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
t:~/tmp/4$ hg ci -m merge
t:~/tmp/4$ hg glog | egrep -v '^[| ]*(user|date):'
@    changeset:   7:f1b4464823a1
|\   tag:         tip
| |  parent:      4:185f1eceafef
| |  parent:      6:25210fe63cbf
| |  summary:     merge
| |
| o    changeset:   6:25210fe63cbf
| |\   parent:      5:e03b50382322
| | |  parent:      3:069c703cd6d4
| | |  summary:     merge
| | |
| | o  changeset:   5:e03b50382322
| | |  parent:      2:b226e84439a9
| | |  summary:     three files
| | |
o---+  changeset:   4:185f1eceafef
| | |  parent:      3:069c703cd6d4
|/ /   parent:      2:b226e84439a9
| |    summary:     merge
| |
o |  changeset:   3:069c703cd6d4
| |  parent:      1:c725ec3c67a1
| |  summary:     two files 2
| |
| o  changeset:   2:b226e84439a9
| |  parent:      0:b100f0270c1c
| |  summary:     second
| |
o |  changeset:   1:c725ec3c67a1
|/   user:        Tikhon Tarnavski
|    summary:     two files
|
o  changeset:   0:b100f0270c1c
   summary:     first

20.04.2010 13:58

t.t писал(а): ↑
20.04.2010 12:38
Получилось немного длинно, но, надеюсь, внятно:

Почти понял. Постоянные метки мне не нравятся совершенно. С моей т.з. незачем сохранять эту информацию для истории и заставлять бесконечно придумывать вразумительные имена.

Кроме того, мне интересен следующий сценарий:
- имеется репозиторий A,
- делается его клон B (например, другим разработчиком),
- в A создаётся бранч b, в нём ведётся разработка и мержится в tip,
- в B создаётся бранч с тем же именем b, в нём ведётся разработка и мержится в tip,
- tip из B мержится в A.
Что будет с бранчем? Будет ли он один или как их различать?

drBatty · Сообщение **drBatty** » 20.04.2010 14:15

/dev/random писал(а): ↑
20.04.2010 08:16
Конечно. Кто ж его будет читать часто, если в нём всего по паре абзацев на каждую команду, немногим больше, чем во встроенной справке ))

так есть hgbook, там куча текста! Мне тоже понравилась документация. Часто гугл даёт неполные, а иногда и неверные решения.

20.04.2010 14:38

Кроме того, если говорить о применении в FOSS, то git на данный момент лучше всех приспособлен для такой разработки. Причина — самоверифицируемость. Hash коммита идентифицирует не только этот отдельный коммит, но и его историю со всеми изменениями. Т.е. зная hash, я могу спокойно потянуть за него коммит с историей с какого-нибудь github или вообще из любого другого источника, и быть совершенно уверен (с вероятностью [2^256 - 1] / 2^256), что это ровно то, что мне надо, что никакой злоумышленник не засунул в код свой зловредный троян и т.п. Никакая другая открытая vcs, насколько мне известно, не имеет такой особенности.

drBatty · Сообщение **drBatty** » 20.04.2010 15:06

watashiwa_darede... писал(а): ↑
20.04.2010 14:38
Hash коммита идентифицирует не только этот отдельный коммит, но и его историю со всеми изменениями. <...>Никакая другая открытая vcs, насколько мне известно, не имеет такой особенности.

разве в hg это не так?

20.04.2010 16:27

drBatty писал(а): ↑
20.04.2010 15:06
разве в hg это не так?

(The Definitive Guide) писал(а):Along with delta or snapshot information, a revlog entry contains a cryptographic hash of the data that it represents. This makes it difficult to forge the contents of a revision, and easy to detect accidental corruption.

Да, действительно так. Только что-то короткий он какой-то...

drBatty · Сообщение **drBatty** » 20.04.2010 16:52

watashiwa_darede... писал(а): ↑
20.04.2010 16:27
Да, действительно так. Только что-то короткий он какой-то...

кто? снапшот или хеш?
в снапшоте только хеши хешей... как бы хеш даже миллиона хешей занимает те-же 256 бит. Т.е. абсолютно не важно, сколько у вас ревизий...

Сообщение **t.t** » 20.04.2010 16:56

watashiwa_daredeska писал(а): ↑
20.04.2010 13:58
t.t писал(а): ↑
20.04.2010 12:38
Получилось немного длинно, но, надеюсь, внятно:
Почти понял. Постоянные метки мне не нравятся совершенно. С моей т.з. незачем сохранять эту информацию для истории и заставлять бесконечно придумывать вразумительные имена.

Я уже написал, что теперь они не постоянные: ветки можно переименовывать или удалять имена.

Кроме того, есть ведь безымянные ветки. Я привёл пример с клонами, но безымянные ветки можно создавать и без клонов. Сейчас тоже пример нарисую.

Вообще, именованные ветки обычно используются для чего-то долгоиграющего. Временные ветки создаются без имён. На мой взгляд, это очень удобно. Кстати, надо будет всё-таки почитать о переименовывании и удалении веток: действительно может пригодиться.

watashiwa_daredeska писал(а): ↑
20.04.2010 13:58
Кроме того, мне интересен следующий сценарий:
- имеется репозиторий A,
- делается его клон B (например, другим разработчиком),
- в A создаётся бранч b, в нём ведётся разработка и мержится в tip,
- в B создаётся бранч с тем же именем b, в нём ведётся разработка и мержится в tip,
- tip из B мержится в A.
Что будет с бранчем? Будет ли он один или как их различать?

Да, здесь возникает коллизия. Сам я с такой ситуацией не сталкивался, да и представить мне её сложно: исходя из самой области применения именованных веток, их никто не создаёт "просто так" -- только "всерьёз и надолго"; в остальных случаях пользуются анонимными. Но насколько я понял из описаний, две ветки с одинаковыми именами существовать могут; но придётся одну из них переименовывать.

Сообщение **t.t** » 20.04.2010 17:02

t.t писал(а): ↑
20.04.2010 16:56
Кроме того, есть ведь безымянные ветки. Я привёл пример с клонами, но безымянные ветки можно создавать и без клонов. Сейчас тоже пример нарисую.

Прошу. На этот раз покороче, т.к. основная суть, думаю, ясна из предыдущих примеров. Здесь только создание безымянной ветки без клонирования хранилища:

Shell

t:~/tmp$ hg init 1; cd 1
t:~/tmp/1$ echo 1 >>file
t:~/tmp/1$ hg add
adding file
t:~/tmp/1$ hg ci -m 1
t:~/tmp/1$ echo 2 >>file
t:~/tmp/1$ hg ci -m 2
t:~/tmp/1$ echo 1 >file2
t:~/tmp/1$ hg add file2
t:~/tmp/1$ hg ci -m "first branch"
t:~/tmp/1$ hg up -r -2
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
t:~/tmp/1$ echo 2 >>file
t:~/tmp/1$ hg ci -m "second branch"
created new head
t:~/tmp/1$ hg glog | egrep -v '^[| ]*(user|date):'
@  changeset:   3:90dddd348e96
|  tag:         tip
|  parent:      1:281b695d5f61
|  summary:     second branch
|
| o  changeset:   2:19d6a7ec3ef3
|/   user:        Tikhon Tarnavski
|    summary:     first branch
|
o  changeset:   1:281b695d5f61
|  summary:     2
|
o  changeset:   0:67894dd6ac3a
   summary:     1

20.04.2010 17:23

t.t писал(а): ↑
20.04.2010 17:02
Здесь только создание безымянной ветки без клонирования хранилища:

Безымянные неудобно. Это надо постоянно смотреть, какой id у head данной ветки. Или нет?

20.04.2010 17:29

drBatty писал(а): ↑
20.04.2010 16:52
кто? снапшот или хеш?

Хеш ченджсета.

drBatty писал(а): ↑
20.04.2010 16:52
как бы хеш даже миллиона хешей занимает те-же 256 бит.

t.t писал(а): ↑
20.04.2010 17:02
changeset: 0:67894dd6ac3a

Не вижу я тут 256 бит. Вижу всего 48. Что записано там, внутри, мне неведомо и злоумышленник может точно также подменить тамошний хеш. Меня интересует, чтобы я мог передать/сохранить в сейфе наряду с адресом репозитория также и хеш некоторого состояния. В git'е этот хеш легко выводится командой git log, без копания в дебрях.

deadhead · Сообщение **deadhead** » 20.04.2010 18:00

Занимательный материал: Many different kinds of revision specifiers, с не менее занимательными комментариями ;-)

drBatty · Сообщение **drBatty** » 20.04.2010 18:16

watashiwa_darede... писал(а): ↑
20.04.2010 17:29
Не вижу я тут 256 бит. Вижу всего 48.

ну это только первые цифры, когда вы делаете pull, то проверяется полный хеш. Кроме того, вы ещё найдите алгоритм подбора (он пока никому не известен) этих 48и бит (даже если остальные отличаются).

watashiwa_darede... писал(а): ↑
20.04.2010 17:29
злоумышленник может точно также подменить тамошний хеш.

ага. щаз! как?

Код: Выделить всё

@  changeset:   21:d48d9a695a1c
|  tag:         tip
|  user:        drBatty emulek <666@gmail.com>
|  date:        Tue Apr 20 18:10:46 2010 +0400

ну и как вы мне что-то подмените? а?

20.04.2010 18:49

drBatty писал(а): ↑
20.04.2010 18:16
ну это только первые цифры, когда вы делаете pull, то проверяется полный хеш.

Проверяется на соответствие чему? В git я храню/передаю полные 256 бит, с ними и сравнивается. А здесь я вижу только 48, мне пофиг сколько их там ещё — если их не видно, то их можно не подделывать.

drBatty писал(а): ↑
20.04.2010 18:16
ну и как вы мне что-то подмените? а?

Это уже другой вопрос, не? Сегодня, может, и никак, а завтра этот подбор любой мобильник за полчаса делать будет. 48 бит — не так уж много, даже вон 3DES хеширование паролей в /etc/shadow заменили на более криптостойкие. 48 бит (или 64?) RSA проломили ещё в прошлом тысячелетии. Правда, не хеш ломали, но буде понадобится, и на хеш управу найдут.

Но это, конечно, весьма минорный недостаток на данный момент, согласен.

Сообщение **t.t** » 20.04.2010 18:59

watashiwa_daredeska писал(а): ↑
20.04.2010 17:23
t.t писал(а): ↑
20.04.2010 17:02
Здесь только создание безымянной ветки без клонирования хранилища:
Безымянные неудобно. Это надо постоянно смотреть, какой id у head данной ветки. Или нет?

В большинстве случаев нет:
1. можно написать что-то вроде такого:

Код: Выделить всё

$ hg up $(hg heads | grep changeset: | grep -vF "$(hg parents | grep changeset:)" | cut -d: -f3 | head -1)

2. в mercurial кроме id есть локальные номера ревизий, по которым можно прыгать в т.ч. и относительно (см. выше: -r -2 -- это "два шага назад", т.е. предпоследняя ревизия).
В тех случаях, когда это неудобно, лучше создать тег или закладку (bookmark).

Кстати, насчёт именованых ветвей. Начиная с 1.2 есть hg ci --close-branch. Начиная (по-моему) с 1.5 есть hg branch --clean. Так что теперь они точно не постоянные. Я когда примеры писал, у меня 1.0.1 стоял; сейчас до 1.5.1 обновился.

t.t писал(а): ↑
20.04.2010 18:59
1. можно написать что-то вроде такого:
Код: Выделить всё
hg up $(hg heads | grep changeset: | grep -vF "$(hg parents | grep changeset:)" | cut -d: -f3 | head -1)

Кстати, спасибо за наводку. (: Очень удобно так прыгать между двумя последними ветками.

Сообщение **t.t** » 20.04.2010 19:05

watashiwa_daredeska, а откуда ты 48 бит взял? Там ведь 12 цифр отображается, а не 6.

20.04.2010 19:13

t.t писал(а): ↑
20.04.2010 19:05
Там ведь 12 цифр отображается, а не 6.

1 hex цифра = 4 bin цифр. Не?

Сообщение **sash-kan** » 20.04.2010 19:27

t.t писал(а): ↑
20.04.2010 04:47
Я не предлагаю сравнивать. Я предлагаю согласиться в том, что:
1. разница есть;
2. эта разница влияет на тот самый "стиль работы" с системой;
3. соответственно, субъективный фактор может присутствовать -- или, другими словами, выбор между git и mercurial зависит _не только_ от набора функций.

1. ещё бы!
2. т.е., ты считаешь, что система _может_ диктовать стиль программирования? да, может.
3. ну конечно же, выбор не зависит от набора функций!
вот на примере твоего выбора для работы: ты же сам написал что-то вроде того, что одним из критериев в польузу hg была именно его ограниченная функциональность (в сравнении с «излишней» функциональностью git-а).
также прекрасным определяющим критерием выбора может быть мнение авторитетного человека.
да мало ли! название длиннее или короче — уже критерий (улыбка) (кстати, озвученный где-то на первой странице топика).
главное — в большинстве случаев выбор субъективен: меня вот «басня о git» сразила на повал, когда я понял, что там совсем не образно (как выглядит на первый взгляд), а вполне конкретно расписано, как устроен репозиторий. и, главное, расписана логика построения этой архитектуры. я поискал что-либо подобное для других vcs, не нашёл. а заглянув «под капот» пары-тройки vcs-ов, начал догадываться, почему для них нет подобных описаний (улыбка). т.е. выбор мой был чисто субъективен — мне понравилась простота архитектуры, которую можно описать даже в виде «басни». возникла чёткая ассоциация:
git-репозиторий — это _как_ plain-text-овый документ. а множество программ для манипулирования с ним (с большим количеством опций у каждой) — как набор gnu-утилит для обработки plain-text-а. а значит git — это наше всё (улыбка), реализация того самого *nix-ового принципа kiss.

Сообщение **t.t** » 20.04.2010 19:32

watashiwa_daredeska писал(а): ↑
20.04.2010 19:13
t.t писал(а): ↑
20.04.2010 19:05
Там ведь 12 цифр отображается, а не 6.
1 hex цифра = 4 bin цифр. Не?

Извини, туплю под вечер.

20.04.2010 19:53

t.t писал(а): ↑
20.04.2010 18:59
2. в mercurial кроме id есть локальные номера ревизий

Без разницы, за чем следить — за id или за номером, они оба меняются.

t.t писал(а): ↑
20.04.2010 18:59
В тех случаях, когда это неудобно, лучше создать тег или закладку (bookmark).

Тег как раз, это логически что-то перманентное. Например, пометка зарелизеной версии, раз и навсегда.
Что такое закладки, я не знаю, не дочитал ещё, но в git такого нет :)

Сообщение **t.t** » 20.04.2010 20:14

sash-kan писал(а): ↑
20.04.2010 19:27
t.t писал(а): ↑
20.04.2010 04:47
Я не предлагаю сравнивать. Я предлагаю согласиться в том, что:
1. разница есть;
2. эта разница влияет на тот самый "стиль работы" с системой;
3. соответственно, субъективный фактор может присутствовать -- или, другими словами, выбор между git и mercurial зависит _не только_ от набора функций.
1. ещё бы!
2. т.е., ты считаешь, что система _может_ диктовать стиль программирования? да, может.

Не передёргивай, пожалуйста. Я говорил о стиле работы с dvcs, а не программирования.

sash-kan писал(а): ↑
20.04.2010 19:27
3. ну конечно же, выбор не зависит от набора функций!

И снова не передёргивай. Я не говорил "_не_ зависит", я сказал "не только". Ведь даже выделил специально -- а ты всё своё... (:

sash-kan писал(а): ↑
20.04.2010 19:27
вот на примере твоего выбора для работы: ты же сам написал что-то вроде того, что одним из критериев в польузу hg была именно его ограниченная функциональность (в сравнении с «излишней» функциональностью git-а).

Не совсем, но в каком-то смысле да: при росте функциональности системы линейно её сложность растёт как минимум квадратично (известная теорема в комбинаторике, числовых системах и других разделах математики). Поэтому раз дополнительная функциональность git для меня излишня, я предпочёл остановиться на более простой системе.

sash-kan писал(а): ↑
20.04.2010 19:27
главное — в большинстве случаев выбор субъективен

Я с этого и начинал. Ты уже передумал, что не согласен с этим? (:

sash-kan писал(а): ↑
20.04.2010 19:27
меня вот «басня о git» сразила на повал, когда я понял, что там совсем не образно (как выглядит на первый взгляд), а вполне конкретно расписано, как устроен репозиторий.

Да, басню я тоже оценил. Но мне не понравилось другое. Репозиторий устроен просто, а вот работа с ним... я пока понял, как грамотно работать с гитовскими ветками, чуть голову не сломал. Да и то, читая сейчас сравнения, понял, что тогда я этого так и не понял.

В mercurial между тем, как я начал вообще читать о понятии ветки и тем, как успешно работал уже и с именованными, и с безымянными ветками, прошло меньше часа. Не говоря уже о том, что голову напрягать мне за это время даже чуточку не пришлось.

Правда, если бы я с самого начала прочитал эту басню, вполне вероятно, что git дался бы мне значительно проще.

watashiwa_daredeska писал(а): ↑
20.04.2010 19:53
t.t писал(а): ↑
20.04.2010 18:59
2. в mercurial кроме id есть локальные номера ревизий
Без разницы, за чем следить — за id или за номером, они оба меняются.

Не совсем, учитывая относительную нумерацию. Но это я скорее к слову упомянул, основной упор был на первый пункт. Кстати, только что понял, как сделать его более универсальным. Сейчас займусь.

watashiwa_daredeska писал(а): ↑
20.04.2010 19:53
t.t писал(а): ↑
20.04.2010 18:59
В тех случаях, когда это неудобно, лучше создать тег или закладку (bookmark).
Тег как раз, это логически что-то перманентное. Например, пометка зарелизеной версии, раз и навсегда.
Что такое закладки, я не знаю, не дочитал ещё, но в git такого нет

Я с ними пока не работал, но из описаний понял, что это как раз что-то вроде временных локальных тегов.

drBatty · Сообщение **drBatty** » 20.04.2010 20:32

watashiwa_darede... писал(а): ↑
20.04.2010 18:49
Проверяется на соответствие чему? В git я храню/передаю полные 256 бит, с ними и сравнивается. А здесь я вижу только 48, мне пофиг сколько их там ещё — если их не видно, то их можно не подделывать.

насколько я понимаю, эти хеши служат для различения коммитов внутри репозитория. Снаружи они не имеют смысла. И я не думаю, что злоумышленник сможет создать ветку с трояном в вашем репозитории, а потом обманом заставит вас включить её в релиз... В конце концов, ваш разработчик вам и без этого гадостей наделать может... Да и вообще... А вот перехватить бандл по дороге, поменять его, и отправить дальше - не получится. Там уже 256 бит в хеше. Т.о. злоумышленник должен иметь доступ к вашему репозиторию. Однако, разве наличие доступа на запись и чтение не делает-ли бессмысленным подделку хеша?

20.04.2010 21:12

t.t писал(а): ↑
20.04.2010 18:59
насчёт именованых ветвей. Начиная с 1.2 есть hg ci --close-branch. Начиная (по-моему) с 1.5 есть hg branch --clean. Так что теперь они точно не постоянные.

Тогда тем более непонятно, нафига их прокачивать из репозитория в репозиторий.
Гипотетическая ситуация.
Допустим, в центральном репозитории бранч 'linux-2.6.30' (не знаю я, как они там зовутся), я клонирую и делаю локальный для нашей команды репозиторий, в котором мы работаем над адаптацией ядра для нескольких наших девайсов. Я делаю бранчи 'model1', 'model2' и т.д. Нам пофиг, какая там версия. Назавтра для какой-то модели решим переползти на 'linux-2.6.32' из центрального репозитория, смержимся и переползём. Нафига нам эти их ветки 'linux-*'? Тем более, если вдруг, налажен двунаправленный pull, наши бранчи им тоже не пришей кобыле хвост, им нужен будет только какой-нибудь 'public-2.6.32'.

unixforum.org

git vs mercurial (было "vcs vs vcs")

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial

Re: git vs mercurial