forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Выпуск распределенной системы управления исходными текстами ..., opennews (??), 28-Июл-15, (0) [смотреть все]

Хоть бы слово про упростили , а то все это консольное вырвиглазие просто невозм, Аноним (-), 16:36 , 28-Июл-15, (1) –33 //

Прочитай уже Pro Git, наконец , Аноним (-), 16:53 , 28-Июл-15, (3) +9 //

Тем более, что Pro Git выложена на официальном сайте git, и даже переведена там , Аноним (-), 00:45 , 29-Июл-15, (30) +2

Надеюсь, что один, так как испортить репоизторий можно только командой rm -rf g, anonymous (??), 16:55 , 28-Июл-15, (4) +1 //

если знаешь магические слова, rshadow (ok), 17:03 , 28-Июл-15, (6) +6
И да, на репозиторий насрать его можно восстановить из другого , главное чтобы , rshadow (ok), 17:06 , 28-Июл-15, (7) +3
откати мне rebase, Аноним (-), 17:15 , 28-Июл-15, (9) –1 //

man git-reflog, waker (ok), 17:20 , 28-Июл-15, (10) +1

DBA сертификаты по Git уже кто-то выдает или еще нет , rshadow (ok), 17:26 , 28-Июл-15, (12)

угу, Git certified CCNA, fail (?), 18:36 , 28-Июл-15, (18) +2

CCNA - это дети в сетях , Аноним (-), 23:22 , 28-Июл-15, (28)

man git-show-ref, Коля (?), 17:24 , 28-Июл-15, (11)
Сам себе duckduckgo com q rebase undo откати , Andrey Mitrofanov (?), 18:33 , 28-Июл-15, (17) +1

Ну я порой бэкаплю перед сложными git rebase -i, чтоб не раскапывать потом git r, Michael Shigorin (ok), 12:30 , 29-Июл-15, (39) //

А временную ветку создать перед ребейзом религия не позволяет , tamerlan311 (?), 14:30 , 29-Июл-15, (45)

до этого места ещё не дочитал, угу , arisu (ok), 14:56 , 29-Июл-15, (47) +1

еще git clean -fdx нельзя откатить, пару раз так терял нужные файлики хоть и не , Аноним (-), 19:47 , 03-Авг-15, (82)

Джавы с джаваскриптом вам мало, так теперь ещё и джит Болезнь-то прогрессирует , derfenix (ok), 17:33 , 28-Июл-15, (13) +1 //

Выпей гин с тоником, Джо (?), 12:34 , 29-Июл-15, (41) //

ох лол Ок, сразу после того, как ты найдёшь в джугле, где его купить подешевле, derfenix (ok), 12:40 , 29-Июл-15, (42)

Напиши стихотворение и выложи на джитхуб , burjui (ok), 13:57 , 29-Июл-15, (43)
gin, giraffe, giant, ginger - читается как дж Недавно узнал в комментах про п, Джо (?), 12:56 , 30-Июл-15, (69)

Думаю, один , Пользователь Debian (?), 17:36 , 28-Июл-15, (14)
Уже давно https www kernel org pub software scm git docs giteveryday html , до, Andrey Mitrofanov (?), 18:29 , 28-Июл-15, (15) +2 //

Smoke git everyday, snoopvcs (?), 17:18 , 30-Июл-15, (70)

Ну так почитайте документацию по git Там хорошо описаны многие моменты https , Аноним (-), 18:52 , 28-Июл-15, (19) –1
Если честно, я это делаю и в hg, и в svn В svn вообще жесть после неудачного бо, Stax (ok), 20:14 , 28-Июл-15, (22) +1
Естественно не один, дураков вокруг достаточно Кто папок с мамками бэкапит, кто, Аноним (-), 05:52 , 29-Июл-15, (34) +1 //

Как, а саму метлу , Michael Shigorin (ok), 12:33 , 29-Июл-15, (40)

Вас таких 95 Правда остальные даже не знают, что такое Git и зачем он нужен О, mine (ok), 10:01 , 29-Июл-15, (36) +3
Специально для вас http www youtube com watch v hkBVAi3oKvo, Аноним (-), 10:34 , 29-Июл-15, (37)
Прочитайте наконец документацию по Git Может это поможет Вам не писать х и и тр, diderevyagin (?), 17:04 , 29-Июл-15, (52)

Не удобная, а универсальная Для удобств есть gitk, gitg, smartgit для нон комме, Ури (?), 16:57 , 28-Июл-15, (5) +3
TortoiseGit под винду и оверхеад как рукой сняло Возможно, самый лучший гип для , ЯвныйОлкоголек (?), 18:32 , 28-Июл-15, (16) –1 //

ой, только не это, оно через такую попу работает, как и все в винде, Ivan1986 (?), 19:27 , 28-Июл-15, (20) +4 //

Если бы ещё под Винду актуальные версии Git были А так на 1 9 5 сидим , программист (?), 19:39 , 28-Июл-15, (21) //

Ну хоть одна хорошая новость за сегодня , Аноним (-), 23:05 , 28-Июл-15, (27) +3

Ну, да Как это здорово Хоть у кого-то хуже чем у тебя, Аноним (-), 00:18 , 29-Июл-15, (29)

Кто-то пользуется виндой и страдает за свои убеждения , Аноним (-), 10:49 , 29-Июл-15, (38)

Я бы пользовался и Linux, если бы была нормальная альтернатива Office и прежде в, программист (?), 13:58 , 29-Июл-15, (44)

Чего только люди не учудят, чтобы не пользоваться Имаксом I I , Andrey Mitrofanov (?), 15:03 , 29-Июл-15, (49) +1

А Имакс тут каким боком , программист (?), 17:36 , 30-Июл-15, (72) –1

Ну как же так https github com git-for-windows git releases, auk (?), 06:16 , 29-Июл-15, (35)

ага, почти stable, Аноним (-), 20:11 , 29-Июл-15, (54)

Вы, вендузятники, должны страдать , Led (ok), 02:47 , 30-Июл-15, (63)

к вопросу по GUI к git ничего ещё не появилось, что может нормально файлы переме, ferux (ok), 21:48 , 28-Июл-15, (24) –1 //

давно всё появилось , all_glory_to_the_hypnotoad (ok), 20:09 , 29-Июл-15, (53)

fossil foreverТам все просто, а если знаешь sql то легко решать проблемы с репоз, fleonis (?), 22:03 , 28-Июл-15, (25) –2 //

Для простых случаев - хорошо, когда легкои просто Но Git настолько распростран, Crazy Alex (ok), 01:56 , 29-Июл-15, (31) +1 //

На счёт не уметь гит согласен куда не сунься, все на нём Но я уже несколько про, fleonis (?), 15:12 , 29-Июл-15, (50) –1 //

Например, rebase как он сделан в git Без этой фичи d VCS совсем не нужна для р, all_glory_to_the_hypnotoad (ok), 20:17 , 29-Июл-15, (55)

вообще-то есть масса workflow, где rebase особо не используется Самое простое -, Crazy Alex (ok), 23:05 , 29-Июл-15, (57) –1

если кодить не хеллоу ворлд, то таких workflow нет Конечно, можно не пользова, all_glory_to_the_hypnotoad (ok), 23:40 , 29-Июл-15, (58) +1

Там есть приватные ветки Они только на один репозиторий Их тоже можно запулить, fleonis (?), 00:32 , 30-Июл-15, (59)

Интересно, это как Вот, есть, например, два последовательных коммита A и B над , all_glory_to_the_hypnotoad (ok), 17:32 , 30-Июл-15, (71)

Разумеется, в основном последовательное деление - но какая разница Главное, что, Crazy Alex (ok), 01:31 , 30-Июл-15, (61)

о, брателло а то я думал, я один такой , arisu (ok), 08:54 , 30-Июл-15, (64)
Такое в разработке проекта на несколько М SLOCов бывает почти никогда, одна фича, all_glory_to_the_hypnotoad (ok), 18:40 , 30-Июл-15, (75)

Я имею в виду, что гит всё равно знать приходится А когда его знаешь уже нет не, Crazy Alex (ok), 23:01 , 29-Июл-15, (56)

Так вот fossil и есть покрупнее Например если над проектом работают четыре чело, fleonis (?), 00:46 , 30-Июл-15, (60)

Вот насчёт интеранционализации я полностью с автором фоссила согласен Впрочем, , Crazy Alex (ok), 01:49 , 30-Июл-15, (62)

ну чего спорите 8208 то фоссил 8212 не гит, и не задумывался, как замена ги, arisu (ok), 09:01 , 30-Июл-15, (65) +1

Да, чего-то я Хватит opennet заси Это кстати круто - Хм Я не вникал в , fleonis (?), 12:08 , 30-Июл-15, (67) –1

а его и не надо трогать, git имеет низкоуровневые команды для манипуляций с базо, arisu (ok), 12:12 , 30-Июл-15, (68) +1

Сам сначала хотел ему написать, потом подумал и не стал, действительно не нужно , fleonis (?), 12:02 , 30-Июл-15, (66) –1

Во Дельную штуку добавили ещё https git-scm com docs git-worktree Теперь мож, ferux (ok), 22:20 , 28-Июл-15, (26) –1 //

А зачем его несколько раз выкачивать Склонируй выкачанный, оно по умолчанию ещё, Crazy Alex (ok), 02:01 , 29-Июл-15, (32) //

прёт его, видимо , arisu (ok), 14:58 , 29-Июл-15, (48) +1

значит вам очень круто повезло А вот push с --force не такая веселая штука И п, ALex_hha (ok), 17:56 , 30-Июл-15, (73) –1 //

а ещё можно мошонку гвоздями к доске прибить виноваты будут, понятно, гвозди и , arisu (ok), 18:22 , 30-Июл-15, (74) +1 //

команда есть и она опасная Или вы потом скажите, так виноват Вася, что не про, ALex_hha (ok), 21:52 , 30-Июл-15, (76) –2 //

откуда дебил 8208 вася узнал о 171 --force 187 вообще тупо скопировал из и, arisu (ok), 22:01 , 30-Июл-15, (77) +1

какая разница откуда он узнал, твоя задача быстро все исправить, а не с пеной у , ALex_hha (ok), 17:34 , 31-Июл-15, (80) –1

нет, у меня не было такой задачи у меня была задача уволить дебила, который не , arisu (ok), 17:37 , 31-Июл-15, (81) +1

Сообщения [Сортировка по времени | RSS]

31. "Выпуск распределенной системы управления исходными текстами ..." +1 +/–

Сообщение от Crazy Alex (ok), 29-Июл-15, 01:56

Для простых случаев - хорошо, когда легкои  просто. Но Git настолько распространён, что не уметь его всё равно нельзя. А раз так - зачем возиться с лишней SCM, которая кроме простоты (в данном случае невостребованной) ничего предложить не может?
Хотя такой, как у фоссила, гибрид проекта в git с вики, пожалуй, мог бы пригодиться по мелочи. Надо глянуть, наверняка кто-то уже сделал подобное.

Ответить | Правка | Наверх | Cообщить модератору

50. "Выпуск распределенной системы управления исходными текстами ..." –1 +/–

Сообщение от fleonis (?), 29-Июл-15, 15:12

На счёт не уметь гит согласен: куда не сунься, все на нём.
Но я уже несколько проектов делаю на fossil, ещё не упёрся в отсутствие функционала. Какие там функции отсутствуют, которые нужны или которые есть в гите?
Там не только вики, там еще и пользователи и просмотр когда и багтрекер :-)

Ответить | Правка | Наверх | Cообщить модератору

55. "Выпуск распределенной системы управления исходными текстами ..." +/–

Сообщение от all_glory_to_the_hypnotoad (ok), 29-Июл-15, 20:17

>  Какие там функции отсутствуют, которые нужны или которые есть в гите?
Например, rebase как он сделан в git. Без этой фичи (d)VCS совсем не нужна для работы с кодом.

Ответить | Правка | Наверх | Cообщить модератору

57. "Выпуск распределенной системы управления исходными текстами ..." –1 +/–

Сообщение от Crazy Alex (ok), 29-Июл-15, 23:05

вообще-то есть масса workflow, где rebase особо не используется. Самое простое - если задача делится на много простых фич/тасков, каждая живёт в своей ветке и merge --squash когда готова, после чего ветка убивается.

Ответить | Правка | Наверх | Cообщить модератору

58. "Выпуск распределенной системы управления исходными текстами ..." +1 +/–

Сообщение от all_glory_to_the_hypnotoad (ok), 29-Июл-15, 23:40

> вообще-то есть масса workflow, где rebase особо не используется.
если кодить не ~ хеллоу ворлд, то таких workflow нет. Конечно, можно не пользоваться ребейзом и делать как-то иначе, но это от неопытности разработчика и/или из-за ограничения используемой VCS.
>  Самое простое - если задача делится на много простых фич/тасков, каждая живёт в своей ветке и merge --squash когда готова
Цикл разработки почти всегда делится на мелкие задачи, но это деление в основном последовательное, а не паралельное. Т.е. нельзя насоздавать сразу N веток и пилить в них одновременно несколько мелких задач. Тут можно развести много бла-бла-бда на тему тщательного планирования и поэтапного выполнения работы, но это невозможно для сколь- нибудь сложного проекта. И это тупо неудобно.
Если ребейзом не пользоваться, то реп сразу же становится помойкой из комитов с коментами типа "fix", а если часто налегать squash, то в сборище беспощадных и бессмысленных мегакоммитов. В общем, во всех вариантах без ребейза реп превращается в тупой инкрементальный бэкап.

Ответить | Правка | Наверх | Cообщить модератору

59. "Выпуск распределенной системы управления исходными текстами ..." +/–

Сообщение от fleonis (?), 30-Июл-15, 00:32

Там есть приватные ветки. Они только на один репозиторий. Их тоже можно запулить в другой, только нужно указать спкцом, что ты этого хочешь.
По мне, так если знаешь sql, то в fossil rebase не нужен: delete все знаменит. А можно просто голову создать, потом закрыть и все, они останутся в истории, будут выглядеть как ветка, только без имени
На fossil он сам и sqlite

Ответить | Правка | Наверх | Cообщить модератору

71. "Выпуск распределенной системы управления исходными текстами ..." +/–

Сообщение от all_glory_to_the_hypnotoad (ok), 30-Июл-15, 17:32

> По мне, так если знаешь sql, то в fossil rebase не нужен: delete все знаменит.
Интересно, это как? Вот, есть, например, два последовательных коммита A и B над одним куском кода. Комит B перемещает редактируемый кусок кода в другой файл + делает некоторые изменения. Хочу ребейзом поменять их местами. git rebase умеет разруливать такие ситуации, в разумных пределах, без конфликтов (см. three-way merge, patch commutation и т.п.), а через тупой delete + add такого ну никак не сделаешь.
По-моему, ты совсем упоролся. Даже если знать хорошо SQL, то всю эту детерминированную машинерию скорее всего не сделаешь никогда. Ты бы ещё посоветовал сразу всё хранить в файликах и руками с ними работать. Ну если, конечно, хорошо знаешь bash, sed и awk.

Ответить | Правка | Наверх | Cообщить модератору

61. "Выпуск распределенной системы управления исходными текстами ..." +/–

Сообщение от Crazy Alex (ok), 30-Июл-15, 01:31

Разумеется, в основном последовательное деление - но какая разница? Главное, чтобы фичи были достаточно небольшими, не первращаясь в монстров при squash - ну так оно при скраме так или иначе полезно. И зачем в каждой ветке пилить несколько задач? Одна задача - одна ветка - один коммит в дев-ветке в итоге. Я, собственно, так работал в весьма немаленьком проекте (скажем так - миллионы строк). Сам, правда, rebase гонял в хвост и в гриву - но ровно потому, что имею привычку коммитить на любой чих с абсолютно бессмысленными мессаджами - просто для своего удобства, как замена stash, а уже потом выгребать из этого нужное. Коллеги без него обходились и обходятся.

Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

64. "Выпуск распределенной системы управления исходными..." +/–

Сообщение от arisu (ok), 30-Июл-15, 08:54

> имею привычку коммитить на любой чих с абсолютно бессмысленными мессаджами -
> просто для своего удобства, как замена stash, а уже потом выгребать
> из этого нужное.
о, брателло! а то я думал, я один такой.

Ответить | Правка | Наверх | Cообщить модератору

75. "Выпуск распределенной системы управления исходными текстами ..." +/–

Сообщение от all_glory_to_the_hypnotoad (ok), 30-Июл-15, 18:40

> Одна задача - одна ветка - один коммит в дев-ветке в итоге .. Я, собственно, так работал в весьма немаленьком проекте (скажем так - миллионы строк)
Такое в разработке проекта на несколько М SLOCов бывает почти никогда, одна фича крайне редко состоит из одной задачи. Типичный цикл разработки содержит следующие типы мелких задач: рефакторинг уже имеющегося кода (в проектах хотя бы от 10К SLOC без этого уже никак), реализация какой-либо отсутствующей функциональности (в библиотеках, в ядре сервиса и т.п.) и, собственно, реализация самой фичи. Это уже минимум три задачи в каких-то простых случаях, причём все они пилятся хронологически одновременно, но логически последовательно.
> Коллеги без него обходились и обходятся.
Ну это не удивительно, сейчас культуре разработке мало где удиляют внимание и, как следствие, мало айти инженеров умеет работать с VCS выше уровня бэкапов или CVS. Хотя уже можно часто встретить требование отделять рефакторинг от создания новых сущностей и функционала.
Вы все поступаете неправильно: твои коллеги, видимо, засирают реп мусорными мелкими бессмысленными коммитами, а ты засираешь мегапатчами (да, я не верю что тебе приходится действительно пилить мало кода для фичи). В итоге ваш реп почти бесполезен в плане истории разработки, ибо...
* нельзя легко понять на чём именно что-то сломалось, т.к. локализация проблемы до гранулярности целой фичи совсем не прикольна, а до мусорного коммита малоинформативна;
* в обоих случаях не понятно что разработчику пришлось интересного сделать во время реализации. Это затрудняет ревью работы и коммуникацию внутри команды и между;
* нельзя легко портировать часть работы в другие ветки;
* пользоваться blame'ом становится трудно, из-за всего выше написанного.

Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

56. "Выпуск распределенной системы управления исходными текстами ..." +/–

Сообщение от Crazy Alex (ok), 29-Июл-15, 23:01

Я имею в виду, что гит всё равно знать приходится. А когда его знаешь уже нет необходимости в "чём-то попроще" - он,  в общем, не сложен, просто кривая освоения крутовата.
Что до пользователей и багтрекера - оно по факту настолько минималистично, что если понадобились пользователи - значит, нужно что-то покрупнее. А для себя вместо багтрекера и файлика .org внутри репы хватает. А вот вики в комплекте - удобно, чтобы всякие нюансы проекта фиксировать даже когда полноценное что-то поднимать лень. Хотя если есть дисциплина и желание - можно всё в доксигене держать, даже красивее выходит.

Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

60. "Выпуск распределенной системы управления исходными текстами ..." +/–

Сообщение от fleonis (?), 30-Июл-15, 00:46

Так вот fossil и есть покрупнее. Например если над проектом работают четыре человека, то как пользователей держать? Я у себя на vps запустил сервер fossil сделал перенаправление на его порт с определённого адреса в ngnix и все, теперь, если я хочу новый репозиторий создать, с пользователям и всеми наворотами, то просто создаю там его файлик и все. Получается полноценный сайт проекта за три минуты (пока дизайн выберешь и я его немного кастомизирую иногда).
Или, например, маленький проект для офиса. Просто запускаешь сервер на своём пк и к тебе могут заходить по ip писать баги и вики - какие-нибудь пояснения...
А с доксигн - это уже настраивать надо... К тому же если написать очень много код не видно :-) меня это в нём раздражает. Маленькая функция, а доков больше чем кода...
Особенно если хочешь чтобы на двух языках :-)
Кстати, на мой взгляд, единственное что я бы хотел видеть ещё в fossil - интернационализация. Но, похоже, автор со мной не согласен, мол надо разработку вести только на одном языке, а не на пяти :-)

Ответить | Правка | Наверх | Cообщить модератору

62. "Выпуск распределенной системы управления исходными текстами ..." +/–

Сообщение от Crazy Alex (ok), 30-Июл-15, 01:49

Вот насчёт интеранционализации я полностью с автором фоссила согласен. Впрочем, я вообще люблю минимизировать количество сущностей (и поэтому предпочитаю не связываться с fossil, зная git). Если человек занимается IT - то английский он знать обречён, а раз так - нечего лишний раз раскладки дрёгать и пытаться тащить русскоязычные кальки с терминов.
А насчёт проектов - я верю, что бывают проекты "на один раз", но я видел только два варианта - либо есть один разработчик, либо какая-то организация/команда. В первом случае в трекере и пользователях смысла нет, а во втором один хрен нужно поднимать инфраструктуру, в которой потом только проекты новые заводят. Тут фоссил как раз не очень, так как в нём все проекты получатся совершенно изолированными, в то время как тот же гитлаб или мантис позволит нормально держать взаимосвязи.
Насчёт офиса - ок, но там непонятно, зачем к этим вики и трекеру VCS :-) Кроме того, для неподготовленного народу оно очень уж аскетичное - даже картинку не вставишь, если не ошибаюсь. Ну и всякие "просто поднимаешь на своём ПК" порождает в перспективе слишком много мороки - либо оно не поднялось когда надо, либо вырубил кто-то машину... Вещи общего пользования должны быть на местном сервере или, на худой конец, где-то на VPS или в облаке. Хотя, конечно, иногда народ копейки экономит - но я бы скорее таких послал.
Доксиген один хрен в серьёзном проекте настраивать надо - ну хотя бы ради того, чтобы код документировался и это каким-то инструментом проверялось. И там он удобен тем, что текстовая болтовня хорошо увязывается с кодом - ссылки и т. п. И я не имел в виду, что большие объёмы текста надо совать в исходники - делаешь отдельные файлы да ссылки на них в содержании. Мороки больше, чем с вики, но результат лучше. Это на чём-то объёмном заметно скорее, когда в голову весь код уже даже близко не помещается, и максимум, что можно объяснить новичку - общую архитектуру.

Ответить | Правка | Наверх | Cообщить модератору

65. "Выпуск распределенной системы управления исходными..." +1 +/–

Сообщение от arisu (ok), 30-Июл-15, 09:01

ну чего спорите‐то? фоссил — не гит, и не задумывался, как замена гита же. у фоссила есть зато уберфича, которой у гита нет: он весь состоит из одного бинаря, а репозиторий — из одной sqlite-базы. бывают ситуации, когда это может быть нужно.
а в остальном — dvcs как dvcs.
2fleonis: в гите тоже можно без проблем рулить низкоуровневым хранилищем — садись да делай свои замены commit, rebase и прочих, если хочется. в смысле — все «кирпичи», из которых высокоуровневые команды построены, спокойно доступны в командной строке.

Ответить | Правка | Наверх | Cообщить модератору

67. "Выпуск распределенной системы управления исходными..." –1 +/–

Сообщение от fleonis (?), 30-Июл-15, 12:08

> ну чего спорите‐то?
Да, чего-то я... Хватит opennet заси****
> фоссил — не гит, и не задумывался, как замена
> гита же. у фоссила есть зато уберфича, которой у гита нет:
> он весь состоит из одного бинаря, а репозиторий — из одной
> sqlite-базы. бывают ситуации, когда это может быть нужно.
Это кстати круто :-)
> 2fleonis: в гите тоже можно без проблем рулить низкоуровневым хранилищем — садись
> да делай свои замены commit, rebase и прочих, если хочется. в
> смысле — все «кирпичи», из которых высокоуровневые команды построены,
> спокойно доступны в командной строке.
Хм.. Я не вникал в содержимое каталога .git , но где-то читал что его лучше не трогать :-)

Ответить | Правка | Наверх | Cообщить модератору

68. "Выпуск распределенной системы управления исходными..." +1 +/–

Сообщение от arisu (ok), 30-Июл-15, 12:12

> Хм.. Я не вникал в содержимое каталога .git , но где-то читал
> что его лучше не трогать :-)
а его и не надо трогать, git имеет низкоуровневые команды для манипуляций с базой. по сути, .git/ — это такое key-value хранилище. как оно там внутри реализовано — не так уж важно, потому что команды для манипуляции ключами и значениями есть прямо в коробке. понимать, конечно, что и как гит хранит, всё ещё надо. сами же вещи типа git init, git commit и прочие как раз используют доступные низкоуровневые команды, а не лазят в хранилище руками.

Ответить | Правка | Наверх | Cообщить модератору

66. "Выпуск распределенной системы управления исходными текстами ..." –1 +/–

Сообщение от fleonis (?), 30-Июл-15, 12:02

> Вот насчёт интеранционализации я полностью с автором фоссила согласен.
Сам сначала хотел ему написать, потом подумал и не стал, действительно не нужно разработку вести на нескольких языках. Он кстати специально не запилил любое изменение истории. Можно только комнтарий подправить, но старая версия все равно будет доступна.
> А насчёт проектов - я верю, что бывают проекты "на один раз",
> но я видел только два варианта - либо есть один разработчик,
> либо какая-то организация/команда. В первом случае в трекере и пользователях смысла
> нет,
Есть: для себя :-) если нужно быстро сделать, то нормальные доки писать некогда да и лень.а вот вики - самое то, когда нужно будет вернуться что-то поправить, то можно быстро вспомнить.
> а во втором один хрен нужно поднимать инфраструктуру, в которой
> потом только проекты новые заводят. Тут фоссил как раз не очень,
> так как в нём все проекты получатся совершенно изолированными, в то
> время как тот же гитлаб или мантис позволит нормально держать взаимосвязи.
Какая взаимосвязь? Субрепы? Они есть, а вот такого колва народу как на гитхабе, конечно нет :-(

> Насчёт офиса - ок, но там непонятно, зачем к этим вики и
> трекеру VCS :-) Кроме того, для неподготовленного народу оно очень уж
> аскетичное - даже картинку не вставишь, если не ошибаюсь. Ну и
Ну.. Я сайт делал, там нужна была админка специфическая. Где  народу описать как пользоваться? Вот пригодилось :-)  а картинки можно вставлять.
Кстати, когда последний сайт делал, заказчик, чуть-чуть разбирался в программировании. Попросил посмотреть :-) я ему ссылку кинул, пользователя создал, показал файла с переменными lesscss :-) он некоторые цвета сам подправил на сайте :-)
> всякие "просто поднимаешь на своём ПК" порождает в перспективе слишком много
> мороки - либо оно не поднялось когда надо, либо вырубил кто-то
> машину... Вещи общего пользования должны быть на местном сервере или, на
> худой конец, где-то на VPS или в облаке.
Ага, я один раз в облаке настроил, теперь там даже маленькие проекты делаю.
Ну, в офисе, как правило, есть свой такой сервер... Он у нас музыку раздаёт :-) там чувак сидит, который ее качает :-) ну и если чего по ssh можно зайти :-)
> Доксиген один хрен в серьёзном проекте настраивать надо - ну хотя бы
> ради того, чтобы код документировался и это каким-то инструментом проверялось. И
> там он удобен тем, что текстовая болтовня хорошо увязывается с кодом
> - ссылки и т. п. И я не имел в виду,
> что большие объёмы текста надо совать в исходники - делаешь отдельные
> файлы да ссылки на них в содержании. Мороки больше, чем с
> вики, но результат лучше. Это на чём-то объёмном заметно скорее, когда
> в голову весь код уже даже близко не помещается, и максимум,
> что можно объяснить новичку - общую архитектуру.
Да, кстати, надо по лучше присмотреться к ссылкам. Да, там удобно диаграммы.
У меня есть обычно файлик, или, если на fossil - wiki, где я пишу цели проекта и roadmap. Мне хватает обычного перечисления, так что не использую специальную систему. Такое в доксиген делать наверное не удобно: если откатишь дерево, то и этот файл тоже уйдет. Я когда с таким файлом работаю и мне нужно полазить по истории, открыватю его,а потом лазию :-)

Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	31. "Выпуск распределенной системы управления исходными текстами ..."	+1 +/–
	Сообщение от Crazy Alex (ok), 29-Июл-15, 01:56
	Для простых случаев - хорошо, когда легкои просто. Но Git настолько распространён, что не уметь его всё равно нельзя. А раз так - зачем возиться с лишней SCM, которая кроме простоты (в данном случае невостребованной) ничего предложить не может? Хотя такой, как у фоссила, гибрид проекта в git с вики, пожалуй, мог бы пригодиться по мелочи. Надо глянуть, наверняка кто-то уже сделал подобное.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	50. "Выпуск распределенной системы управления исходными текстами ..."	–1 +/–
	Сообщение от fleonis (?), 29-Июл-15, 15:12
	На счёт не уметь гит согласен: куда не сунься, все на нём. Но я уже несколько проектов делаю на fossil, ещё не упёрся в отсутствие функционала. Какие там функции отсутствуют, которые нужны или которые есть в гите? Там не только вики, там еще и пользователи и просмотр когда и багтрекер :-)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	55. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 29-Июл-15, 20:17
	> Какие там функции отсутствуют, которые нужны или которые есть в гите? Например, rebase как он сделан в git. Без этой фичи (d)VCS совсем не нужна для работы с кодом.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	57. "Выпуск распределенной системы управления исходными текстами ..."	–1 +/–
	Сообщение от Crazy Alex (ok), 29-Июл-15, 23:05
	вообще-то есть масса workflow, где rebase особо не используется. Самое простое - если задача делится на много простых фич/тасков, каждая живёт в своей ветке и merge --squash когда готова, после чего ветка убивается.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	58. "Выпуск распределенной системы управления исходными текстами ..."	+1 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 29-Июл-15, 23:40
	> вообще-то есть масса workflow, где rebase особо не используется. если кодить не ~ хеллоу ворлд, то таких workflow нет. Конечно, можно не пользоваться ребейзом и делать как-то иначе, но это от неопытности разработчика и/или из-за ограничения используемой VCS. > Самое простое - если задача делится на много простых фич/тасков, каждая живёт в своей ветке и merge --squash когда готова Цикл разработки почти всегда делится на мелкие задачи, но это деление в основном последовательное, а не паралельное. Т.е. нельзя насоздавать сразу N веток и пилить в них одновременно несколько мелких задач. Тут можно развести много бла-бла-бда на тему тщательного планирования и поэтапного выполнения работы, но это невозможно для сколь- нибудь сложного проекта. И это тупо неудобно. Если ребейзом не пользоваться, то реп сразу же становится помойкой из комитов с коментами типа "fix", а если часто налегать squash, то в сборище беспощадных и бессмысленных мегакоммитов. В общем, во всех вариантах без ребейза реп превращается в тупой инкрементальный бэкап.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	59. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от fleonis (?), 30-Июл-15, 00:32
	Там есть приватные ветки. Они только на один репозиторий. Их тоже можно запулить в другой, только нужно указать спкцом, что ты этого хочешь. По мне, так если знаешь sql, то в fossil rebase не нужен: delete все знаменит. А можно просто голову создать, потом закрыть и все, они останутся в истории, будут выглядеть как ветка, только без имени На fossil он сам и sqlite
	Ответить \| Правка \| Наверх \| Cообщить модератору


	71. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 30-Июл-15, 17:32
	> По мне, так если знаешь sql, то в fossil rebase не нужен: delete все знаменит. Интересно, это как? Вот, есть, например, два последовательных коммита A и B над одним куском кода. Комит B перемещает редактируемый кусок кода в другой файл + делает некоторые изменения. Хочу ребейзом поменять их местами. git rebase умеет разруливать такие ситуации, в разумных пределах, без конфликтов (см. three-way merge, patch commutation и т.п.), а через тупой delete + add такого ну никак не сделаешь. По-моему, ты совсем упоролся. Даже если знать хорошо SQL, то всю эту детерминированную машинерию скорее всего не сделаешь никогда. Ты бы ещё посоветовал сразу всё хранить в файликах и руками с ними работать. Ну если, конечно, хорошо знаешь bash, sed и awk.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	61. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Crazy Alex (ok), 30-Июл-15, 01:31
	Разумеется, в основном последовательное деление - но какая разница? Главное, чтобы фичи были достаточно небольшими, не первращаясь в монстров при squash - ну так оно при скраме так или иначе полезно. И зачем в каждой ветке пилить несколько задач? Одна задача - одна ветка - один коммит в дев-ветке в итоге. Я, собственно, так работал в весьма немаленьком проекте (скажем так - миллионы строк). Сам, правда, rebase гонял в хвост и в гриву - но ровно потому, что имею привычку коммитить на любой чих с абсолютно бессмысленными мессаджами - просто для своего удобства, как замена stash, а уже потом выгребать из этого нужное. Коллеги без него обходились и обходятся.
	Ответить \| Правка \| К родителю #58 \| Наверх \| Cообщить модератору


	64. "Выпуск распределенной системы управления исходными..."	+/–
	Сообщение от arisu (ok), 30-Июл-15, 08:54
	> имею привычку коммитить на любой чих с абсолютно бессмысленными мессаджами - > просто для своего удобства, как замена stash, а уже потом выгребать > из этого нужное. о, брателло! а то я думал, я один такой.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	75. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 30-Июл-15, 18:40
	> Одна задача - одна ветка - один коммит в дев-ветке в итоге .. Я, собственно, так работал в весьма немаленьком проекте (скажем так - миллионы строк) Такое в разработке проекта на несколько М SLOCов бывает почти никогда, одна фича крайне редко состоит из одной задачи. Типичный цикл разработки содержит следующие типы мелких задач: рефакторинг уже имеющегося кода (в проектах хотя бы от 10К SLOC без этого уже никак), реализация какой-либо отсутствующей функциональности (в библиотеках, в ядре сервиса и т.п.) и, собственно, реализация самой фичи. Это уже минимум три задачи в каких-то простых случаях, причём все они пилятся хронологически одновременно, но логически последовательно. > Коллеги без него обходились и обходятся. Ну это не удивительно, сейчас культуре разработке мало где удиляют внимание и, как следствие, мало айти инженеров умеет работать с VCS выше уровня бэкапов или CVS. Хотя уже можно часто встретить требование отделять рефакторинг от создания новых сущностей и функционала. Вы все поступаете неправильно: твои коллеги, видимо, засирают реп мусорными мелкими бессмысленными коммитами, а ты засираешь мегапатчами (да, я не верю что тебе приходится действительно пилить мало кода для фичи). В итоге ваш реп почти бесполезен в плане истории разработки, ибо... * нельзя легко понять на чём именно что-то сломалось, т.к. локализация проблемы до гранулярности целой фичи совсем не прикольна, а до мусорного коммита малоинформативна; * в обоих случаях не понятно что разработчику пришлось интересного сделать во время реализации. Это затрудняет ревью работы и коммуникацию внутри команды и между; * нельзя легко портировать часть работы в другие ветки; * пользоваться blame'ом становится трудно, из-за всего выше написанного.
	Ответить \| Правка \| К родителю #61 \| Наверх \| Cообщить модератору


	56. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Crazy Alex (ok), 29-Июл-15, 23:01
	Я имею в виду, что гит всё равно знать приходится. А когда его знаешь уже нет необходимости в "чём-то попроще" - он, в общем, не сложен, просто кривая освоения крутовата. Что до пользователей и багтрекера - оно по факту настолько минималистично, что если понадобились пользователи - значит, нужно что-то покрупнее. А для себя вместо багтрекера и файлика .org внутри репы хватает. А вот вики в комплекте - удобно, чтобы всякие нюансы проекта фиксировать даже когда полноценное что-то поднимать лень. Хотя если есть дисциплина и желание - можно всё в доксигене держать, даже красивее выходит.
	Ответить \| Правка \| К родителю #50 \| Наверх \| Cообщить модератору


	60. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от fleonis (?), 30-Июл-15, 00:46
	Так вот fossil и есть покрупнее. Например если над проектом работают четыре человека, то как пользователей держать? Я у себя на vps запустил сервер fossil сделал перенаправление на его порт с определённого адреса в ngnix и все, теперь, если я хочу новый репозиторий создать, с пользователям и всеми наворотами, то просто создаю там его файлик и все. Получается полноценный сайт проекта за три минуты (пока дизайн выберешь и я его немного кастомизирую иногда). Или, например, маленький проект для офиса. Просто запускаешь сервер на своём пк и к тебе могут заходить по ip писать баги и вики - какие-нибудь пояснения... А с доксигн - это уже настраивать надо... К тому же если написать очень много код не видно :-) меня это в нём раздражает. Маленькая функция, а доков больше чем кода... Особенно если хочешь чтобы на двух языках :-) Кстати, на мой взгляд, единственное что я бы хотел видеть ещё в fossil - интернационализация. Но, похоже, автор со мной не согласен, мол надо разработку вести только на одном языке, а не на пяти :-)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	62. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Crazy Alex (ok), 30-Июл-15, 01:49
	Вот насчёт интеранционализации я полностью с автором фоссила согласен. Впрочем, я вообще люблю минимизировать количество сущностей (и поэтому предпочитаю не связываться с fossil, зная git). Если человек занимается IT - то английский он знать обречён, а раз так - нечего лишний раз раскладки дрёгать и пытаться тащить русскоязычные кальки с терминов. А насчёт проектов - я верю, что бывают проекты "на один раз", но я видел только два варианта - либо есть один разработчик, либо какая-то организация/команда. В первом случае в трекере и пользователях смысла нет, а во втором один хрен нужно поднимать инфраструктуру, в которой потом только проекты новые заводят. Тут фоссил как раз не очень, так как в нём все проекты получатся совершенно изолированными, в то время как тот же гитлаб или мантис позволит нормально держать взаимосвязи. Насчёт офиса - ок, но там непонятно, зачем к этим вики и трекеру VCS :-) Кроме того, для неподготовленного народу оно очень уж аскетичное - даже картинку не вставишь, если не ошибаюсь. Ну и всякие "просто поднимаешь на своём ПК" порождает в перспективе слишком много мороки - либо оно не поднялось когда надо, либо вырубил кто-то машину... Вещи общего пользования должны быть на местном сервере или, на худой конец, где-то на VPS или в облаке. Хотя, конечно, иногда народ копейки экономит - но я бы скорее таких послал. Доксиген один хрен в серьёзном проекте настраивать надо - ну хотя бы ради того, чтобы код документировался и это каким-то инструментом проверялось. И там он удобен тем, что текстовая болтовня хорошо увязывается с кодом - ссылки и т. п. И я не имел в виду, что большие объёмы текста надо совать в исходники - делаешь отдельные файлы да ссылки на них в содержании. Мороки больше, чем с вики, но результат лучше. Это на чём-то объёмном заметно скорее, когда в голову весь код уже даже близко не помещается, и максимум, что можно объяснить новичку - общую архитектуру.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	65. "Выпуск распределенной системы управления исходными..."	+1 +/–
	Сообщение от arisu (ok), 30-Июл-15, 09:01
	ну чего спорите‐то? фоссил — не гит, и не задумывался, как замена гита же. у фоссила есть зато уберфича, которой у гита нет: он весь состоит из одного бинаря, а репозиторий — из одной sqlite-базы. бывают ситуации, когда это может быть нужно. а в остальном — dvcs как dvcs. 2fleonis: в гите тоже можно без проблем рулить низкоуровневым хранилищем — садись да делай свои замены commit, rebase и прочих, если хочется. в смысле — все «кирпичи», из которых высокоуровневые команды построены, спокойно доступны в командной строке.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	67. "Выпуск распределенной системы управления исходными..."	–1 +/–
	Сообщение от fleonis (?), 30-Июл-15, 12:08
	> ну чего спорите‐то? Да, чего-то я... Хватит opennet заси**** > фоссил — не гит, и не задумывался, как замена > гита же. у фоссила есть зато уберфича, которой у гита нет: > он весь состоит из одного бинаря, а репозиторий — из одной > sqlite-базы. бывают ситуации, когда это может быть нужно. Это кстати круто :-) > 2fleonis: в гите тоже можно без проблем рулить низкоуровневым хранилищем — садись > да делай свои замены commit, rebase и прочих, если хочется. в > смысле — все «кирпичи», из которых высокоуровневые команды построены, > спокойно доступны в командной строке. Хм.. Я не вникал в содержимое каталога .git , но где-то читал что его лучше не трогать :-)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	68. "Выпуск распределенной системы управления исходными..."	+1 +/–
	Сообщение от arisu (ok), 30-Июл-15, 12:12
	> Хм.. Я не вникал в содержимое каталога .git , но где-то читал > что его лучше не трогать :-) а его и не надо трогать, git имеет низкоуровневые команды для манипуляций с базой. по сути, .git/ — это такое key-value хранилище. как оно там внутри реализовано — не так уж важно, потому что команды для манипуляции ключами и значениями есть прямо в коробке. понимать, конечно, что и как гит хранит, всё ещё надо. сами же вещи типа git init, git commit и прочие как раз используют доступные низкоуровневые команды, а не лазят в хранилище руками.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	66. "Выпуск распределенной системы управления исходными текстами ..."	–1 +/–
	Сообщение от fleonis (?), 30-Июл-15, 12:02
	> Вот насчёт интеранционализации я полностью с автором фоссила согласен. Сам сначала хотел ему написать, потом подумал и не стал, действительно не нужно разработку вести на нескольких языках. Он кстати специально не запилил любое изменение истории. Можно только комнтарий подправить, но старая версия все равно будет доступна. > А насчёт проектов - я верю, что бывают проекты "на один раз", > но я видел только два варианта - либо есть один разработчик, > либо какая-то организация/команда. В первом случае в трекере и пользователях смысла > нет, Есть: для себя :-) если нужно быстро сделать, то нормальные доки писать некогда да и лень.а вот вики - самое то, когда нужно будет вернуться что-то поправить, то можно быстро вспомнить. > а во втором один хрен нужно поднимать инфраструктуру, в которой > потом только проекты новые заводят. Тут фоссил как раз не очень, > так как в нём все проекты получатся совершенно изолированными, в то > время как тот же гитлаб или мантис позволит нормально держать взаимосвязи. Какая взаимосвязь? Субрепы? Они есть, а вот такого колва народу как на гитхабе, конечно нет :-( > Насчёт офиса - ок, но там непонятно, зачем к этим вики и > трекеру VCS :-) Кроме того, для неподготовленного народу оно очень уж > аскетичное - даже картинку не вставишь, если не ошибаюсь. Ну и Ну.. Я сайт делал, там нужна была админка специфическая. Где народу описать как пользоваться? Вот пригодилось :-) а картинки можно вставлять. Кстати, когда последний сайт делал, заказчик, чуть-чуть разбирался в программировании. Попросил посмотреть :-) я ему ссылку кинул, пользователя создал, показал файла с переменными lesscss :-) он некоторые цвета сам подправил на сайте :-) > всякие "просто поднимаешь на своём ПК" порождает в перспективе слишком много > мороки - либо оно не поднялось когда надо, либо вырубил кто-то > машину... Вещи общего пользования должны быть на местном сервере или, на > худой конец, где-то на VPS или в облаке. Ага, я один раз в облаке настроил, теперь там даже маленькие проекты делаю. Ну, в офисе, как правило, есть свой такой сервер... Он у нас музыку раздаёт :-) там чувак сидит, который ее качает :-) ну и если чего по ssh можно зайти :-) > Доксиген один хрен в серьёзном проекте настраивать надо - ну хотя бы > ради того, чтобы код документировался и это каким-то инструментом проверялось. И > там он удобен тем, что текстовая болтовня хорошо увязывается с кодом > - ссылки и т. п. И я не имел в виду, > что большие объёмы текста надо совать в исходники - делаешь отдельные > файлы да ссылки на них в содержании. Мороки больше, чем с > вики, но результат лучше. Это на чём-то объёмном заметно скорее, когда > в голову весь код уже даже близко не помещается, и максимум, > что можно объяснить новичку - общую архитектуру. Да, кстати, надо по лучше присмотреться к ссылкам. Да, там удобно диаграммы. У меня есть обычно файлик, или, если на fossil - wiki, где я пишу цели проекта и roadmap. Мне хватает обычного перечисления, так что не использую специальную систему. Такое в доксиген делать наверное не удобно: если откатишь дерево, то и этот файл тоже уйдет. Я когда с таким файлом работаю и мне нужно полазить по истории, открыватю его,а потом лазию :-)
	Ответить \| Правка \| К родителю #62 \| Наверх \| Cообщить модератору