У вас один стиль, у нас другой. Вы сторонник восходящего проектирования, когда сущности создаются по мере необходимости, я — сторонник нисходящего, когда сначала формируется скелет, который потом обрастает мясом.
И то, и другое — хорошие, жизнеспособные подходы, но только один из них поддерживается Git-ом, а другой — нет. Если вы никогда не будете использовать нисходящий подход, то, возможно, вы никогда и не заметите этого ограничения. Но ведь есть и сторонники других подходов, не так ли? А такая штука как система контроля версий должна подразумевать определенную долю универсальности.
Отвечу всем сразу, высказавшим мнение о составлении письменной спецификации: административной проблемы в данной ситуации не существует. Команда дружная и не собирается загаживать проект. Все согласны, что структура должна быть.
Просто должен быть кто-то, кто эти папки однажды создаст, чтобы потом, когда людям нужно будет добавить CSS файл, они не лезли в спецификацию, и не вычитывали бы правила именования файлов, а просто положили бы его в уже подготовленную папку.
Зачем плодить документы и бюрократию, когда достаточно создать 5-7 папок?
Допустим я начинаю веб-приложение. Мне важно, чтобы в команде было единое мнение по поводу того, куда должны класться CSS, JS файлы, файлы картинок, шаблонов, SQL дампов и прочего.
Для этого я создаю структуру каталогов, в которой создаю пустые папки под js, css, пд картинки, под аплоады, под классы, ресурсы и прочее. Теперь другие разработчики будут следовать данной иерархии и, если надо, изменять или дополнять ее, не создавая при этом анархии. Со временем эти папки наполнятся, а ненужные удалятся, но в начале пути мне необходимо чтобы они были и были при этом пустыми.
Почему инструмент разработки должен диктовать, что мол «неет, братец, тебе не нужны пустые папки»?
Т.е. различие заключается в том, что в Git локальные репозитории дублирует всю историю изменений, в SVN же — только текущую ревизию. Поэтому если вдруг не дай Бог что произойдет с центральным сервером, то по Git-у мы восстановим все ревизии, а по SVN — только последнюю.
Наиболее простой и удобный способ — это выделить один репозиторий для обмена.
Абсолютно с вами согласен. Но по сути у нас это ведь получается эквивалентом централизованной системы разработки. А команды формирования патча, который может быть переслан через e-mail, есть и в SVN — svn diff / svn patch.
Я так понимаю, что речь идет про git+ssh? Честно скажу, Git я собрался использовать после того как посмотрел презентацию Git-а на Google Tech Days, проводимую самим Линусом Торвальдсом (линк). Там был вот такой кадр:
Глядя на нее, я ожидал поддержки p2p соединений на уровне самого Git-а. Например, подключение на удаленный адрес: порт, открываемый коллегой, либо чего-то в этом роде.
А получается, что все эти веселые смайлики сидят исключительно на *nix машинах, на каждом установлен и настроен SSHd, созданы аккаунты для каждого из соседей (!!!), а когда появляется новый член, все, видимо, дружно создают ему по аккаунту, когда уходит — дружно его удаляют. Кроме того, SSH — это ведь как бы не только Git, не так ли? Значит за каждым из компов сидит сисадмин, который не поленился настроить должным образом систему и SSHd, чтобы обеспечить безопасность пребывания малознакомых людей на своем десктопе.
Наверняка, найдутся ситуации, когда это будет не просто возможно, но и полезно и необходимо. Но так ли все просто и радужно на самом деле, как в рекламе? Используется ли реально Git именно для децентрализации, а не только для легкого управления ветками?
P.S: судя по количеству минусов, которые были получены в карму, на фоне отсутствия конструктивного диалога — интерес и правда «нездоровый». Кто-то воспринял критику Git-а как личное оскорбления что ли?
Какое-то последнее время нездоровое количество визга по поводу Git-а. Был у меня один проект, который надо было делать вдвоем, а сервер поднимать не хотелось. Поставили Git, зачли репозитарий.
Сразу же выяснилось — в Git-е нельзя создать пустую папку. Мелочь, скажете вы? Вроде бы да, но, согласитесь, пустые папки бывают нужны — например, папка для данных приложения, которая будет потом заполняться рантаймом, а так же начальная структура каталогов. Пришлось всюду положить по пустому файлу, что само по себе костыль.
Дальше — больше. Хорошо, начальная структура каталогов, первый проект — все это было сделано, закоммичено, проблем не вызвало. Что дальше? А дельше надо передать проект своему напарнику. И тут выяснятся, что сделать этого напрямую мы не можем. Что надо поднимать либо веб-сервис с WebDav, либо чтобы он имел доступ к моей ФС, либо поднимать git-server. Напрямую p2p два клиента без поднимания костылей подключиться и сделать push не могут. А значит все равно нужен какой-то эталонный центральный сервер.
А если все равно нужен центральный сервер, то в чем прелесть? По сути — только в простом управлении ветками. Причем именно в их создании/удалении, т.к. опции типа редактирования коммитов — это, конечно, клево, но так ли уж сильно нужно?
Увы и ах, вы сами сказали ключевую фразу — "на собственном опыте пришел к...". Остальные ничем не хуже и не лучше вас — они вместо того, чтобы довериться книгам или подобным статьям, предпочитают приходить ко всему «на собственном опыте», ломая горы копий о неприступные стены, когда обходные пути открыты и известны.
Но кто же поверит автору, пока не придет на пресловутом собственном опыте?
Самое веселое в этом, что Микрософт (а Bing ведь их компания!) делает Bing под эппловский вебкит, а про возможность это все посмотреть даже на IE9 галантно умалчивается.
… и еще за количество запросов, и за количество обращений, и за все-все подряд. А с учетом, что 0.02 это цена в США, а в европе — 0.025, то цена в 40-50$ за такую конфигурацию в месяц — выглядит не так уж и привлекательно для малых проектов, и с трудом конкурирует с VDS. Хотя бы потому, что на VDS платишь фиксированную сумму и не беспокоишься о том, что кто-то посадит на траффик.
Но для тех, кто, например, развивает небольшой проект с перспективой обширного роста — очень даже любопытно. Однако опять же — ниразу не дешево.
Возможно, дублировать. Как бы на вкус и цвет, фломастеры разные, но поймите сами — автор лично мне не известен (топ-менеджеров и разных просветителей как собак нерезаных сейчас, вы это знаете), тема вроде как интересна, но есть сомнения.
Если подкаст — то включу его в колонки, пока буду обедать, то прослушаю. Заодно может умней стану. Или пока домой/из дома ехать буду. Этого времени не жалко, т.к. все равно пока я ем, то чем-то более полезным не смогу заниматься, и в этом подкасты рулят.
Когда же сидишь за компьютером, то есть куча других дел, и если тратить по 20 минут на каждого машущего руками мужика — то никакой жизни не хватит. Гораздо полезней прочитать хорошую книгу.
ИМХО видео, на котором просто сидит мужик и размахивает руками должно быть оформлено либо:
— в виде подкаста, чтобы его можно было прослушать по дороге домой
— в виде текста, чтобы можно было что-то копировать в заметки, ставить закладки, делиться с другими, пропускать какие-то части, или прочитать наискосок.
Давайте ибо сравнивать случай когда и база mysql в памяти, и у couchdb в дисковом кеше, либо когда ни та, ни другая не находится в кеше/памяти.
Потому как иначе такое сравнение не очень-то легитимно. Ведь дисковый кэш — это по сути та же память, а значит если на вашу БД хватает дискового кеша, то скорей всего хватило бы и памяти mysql-у (конечно, с оговорками, но все же). И наоборот — если не хватает памяти, то не хватит и кеша.
Как-то не кажется ли вам, что железяка (или монтажник, осуществляющий сборку компьютера с учетом отвода образуемого тепла) должна сама заботиться о своей температуре, а не перекладывать это на плечи программиста!
А то давайте еще начинать в программу sleep()-ы вставлять, чтобы процессор не грелся!
И то, и другое — хорошие, жизнеспособные подходы, но только один из них поддерживается Git-ом, а другой — нет. Если вы никогда не будете использовать нисходящий подход, то, возможно, вы никогда и не заметите этого ограничения. Но ведь есть и сторонники других подходов, не так ли? А такая штука как система контроля версий должна подразумевать определенную долю универсальности.
Просто должен быть кто-то, кто эти папки однажды создаст, чтобы потом, когда людям нужно будет добавить CSS файл, они не лезли в спецификацию, и не вычитывали бы правила именования файлов, а просто положили бы его в уже подготовленную папку.
Зачем плодить документы и бюрократию, когда достаточно создать 5-7 папок?
Для этого я создаю структуру каталогов, в которой создаю пустые папки под js, css, пд картинки, под аплоады, под классы, ресурсы и прочее. Теперь другие разработчики будут следовать данной иерархии и, если надо, изменять или дополнять ее, не создавая при этом анархии. Со временем эти папки наполнятся, а ненужные удалятся, но в начале пути мне необходимо чтобы они были и были при этом пустыми.
Почему инструмент разработки должен диктовать, что мол «неет, братец, тебе не нужны пустые папки»?
Правильно я понял?
Абсолютно с вами согласен. Но по сути у нас это ведь получается эквивалентом централизованной системы разработки. А команды формирования патча, который может быть переслан через e-mail, есть и в SVN — svn diff / svn patch.
Глядя на нее, я ожидал поддержки p2p соединений на уровне самого Git-а. Например, подключение на удаленный адрес: порт, открываемый коллегой, либо чего-то в этом роде.
А получается, что все эти веселые смайлики сидят исключительно на *nix машинах, на каждом установлен и настроен SSHd, созданы аккаунты для каждого из соседей (!!!), а когда появляется новый член, все, видимо, дружно создают ему по аккаунту, когда уходит — дружно его удаляют. Кроме того, SSH — это ведь как бы не только Git, не так ли? Значит за каждым из компов сидит сисадмин, который не поленился настроить должным образом систему и SSHd, чтобы обеспечить безопасность пребывания малознакомых людей на своем десктопе.
Наверняка, найдутся ситуации, когда это будет не просто возможно, но и полезно и необходимо. Но так ли все просто и радужно на самом деле, как в рекламе? Используется ли реально Git именно для децентрализации, а не только для легкого управления ветками?
P.S: судя по количеству минусов, которые были получены в карму, на фоне отсутствия конструктивного диалога — интерес и правда «нездоровый». Кто-то воспринял критику Git-а как личное оскорбления что ли?
Сразу же выяснилось — в Git-е нельзя создать пустую папку. Мелочь, скажете вы? Вроде бы да, но, согласитесь, пустые папки бывают нужны — например, папка для данных приложения, которая будет потом заполняться рантаймом, а так же начальная структура каталогов. Пришлось всюду положить по пустому файлу, что само по себе костыль.
Дальше — больше. Хорошо, начальная структура каталогов, первый проект — все это было сделано, закоммичено, проблем не вызвало. Что дальше? А дельше надо передать проект своему напарнику. И тут выяснятся, что сделать этого напрямую мы не можем. Что надо поднимать либо веб-сервис с WebDav, либо чтобы он имел доступ к моей ФС, либо поднимать git-server. Напрямую p2p два клиента без поднимания костылей подключиться и сделать push не могут. А значит все равно нужен какой-то эталонный центральный сервер.
А если все равно нужен центральный сервер, то в чем прелесть? По сути — только в простом управлении ветками. Причем именно в их создании/удалении, т.к. опции типа редактирования коммитов — это, конечно, клево, но так ли уж сильно нужно?
Но кто же поверит автору, пока не придет на пресловутом собственном опыте?
Но для тех, кто, например, развивает небольшой проект с перспективой обширного роста — очень даже любопытно. Однако опять же — ниразу не дешево.
Если подкаст — то включу его в колонки, пока буду обедать, то прослушаю. Заодно может умней стану. Или пока домой/из дома ехать буду. Этого времени не жалко, т.к. все равно пока я ем, то чем-то более полезным не смогу заниматься, и в этом подкасты рулят.
Когда же сидишь за компьютером, то есть куча других дел, и если тратить по 20 минут на каждого машущего руками мужика — то никакой жизни не хватит. Гораздо полезней прочитать хорошую книгу.
— в виде подкаста, чтобы его можно было прослушать по дороге домой
— в виде текста, чтобы можно было что-то копировать в заметки, ставить закладки, делиться с другими, пропускать какие-то части, или прочитать наискосок.
Потому как иначе такое сравнение не очень-то легитимно. Ведь дисковый кэш — это по сути та же память, а значит если на вашу БД хватает дискового кеша, то скорей всего хватило бы и памяти mysql-у (конечно, с оговорками, но все же). И наоборот — если не хватает памяти, то не хватит и кеша.
А то давайте еще начинать в программу sleep()-ы вставлять, чтобы процессор не грелся!