Может стоит научится пользоваться молотком? Да, молотки бывают разные и для разных целей. А еще у них бывают разные ручки — одни удобнее, другие нет.
Вот svn в качестве молотка отвратителен — сбитый боек, треснутая ручка, не работает когда не подключен к интернету, не работает, когда нужен сразу нескольким трудягам — один ручку забрал, другой боек и ни у одного не получается забить гвоздь.
А когда им обоим говорят — вот, возьмите бесплатно каждый по новому молотку с удобной ручкой, говорят нет, у новых молотков ручка слишком удобная, не привычно, тяжело себе по пальцам ударить…
Зачем мне две команды на одно действие? Глупость какая-то.
Это разные действия).
Вы хотите спрятать подробности разработки от сообщества? Не понимаю, зачем это надо. Мне лично нечего скрывать в своём коде.
Прятать? Вы о чем? Я не хочу, чтобы недоделанная задача повлияла на пару десятков других разработчиков. В svn это сложно.
Причина в том, что мне не нужны эти операции по отдельности, потому я не понимаю, зачем их разделили.
А многим нужны именно по отдельности. И желание появилось не на ровном месте.
Приведите пример, зачем это может быть нужно.
Я уже приводил выше: решение одной большой задачи итерационно, разбивая ее на множество мелких.
Зачем работать с 3 ветками одновременно? Создайте свою и работайте в ней, потом затащите изменения из неё в другие. Создаёте проблемы на пустом месте.
Можно я не буду на это отвечать?)))
Я теперь не могу работать над своим кодом в сообществах, используя SVN, понимаете?
И это хорошо! Чем меньше плохого инструмента в обращении — тем лучше.
Мне вот не нравится drupal, но это не означает что он плохой, верно? Хотя нет — для меня он ужасен.
А для меня извращенцы — это пользователи git
На вкус и цвет… Если-бы svn был удобен — с него не убегали бы. А с него бегут. Не только в git, но и в hg и в bazaar. Бегут именно по причине того, что svn не дает работать.
Думаю, на этом и закончим. Мне уже понятно, что у вас чисто эмоциональная неприязнь инструмента.
Странное решение проблем. Да еще и «несколько раз в день».
Итак, если при коммите возникла какая-то очередная непонятная ошибка
Например? Мне кажется — вы сейчас сильно лукавите. Если проблема в коммите — у вас проблема с настройками и/или правами. Если в пуше — значит у вас конфликт, который легко разруливается. А ваш «рецепт» похож на мазохизм, из серии «пусть мне будет плохо, но я так хочу»…
Я пишу код и хочу, чтобы он, чёрт побери, попал в сетевую репу в нужную ветку.
Круто. git commit & git push. В чем проблема? А как сделать в svn, чтобы в сетевую репу не попали куча разных коммитов, а попал только один, финальный?
В SVN это делается одной командой.
Верно. Потому (только не злитесь) что svn ущербен. На большее, кроме как получить/отдать, он от рождения не способен. Да, в простых случаях этого хватает. Но не всем и не всегда.
Зачем сливать коммиты?
Чтобы в истории видеть 1 коммит = 1 задаче, но при этом в разработке дробить эту задачу на 100500 мелких и решать их отдельно разными коммитами.
Не пуше каком-то, я не понимаю что это такое и зачем это нужно.
Ну так вот она проблема, а не в гите ;). Ну серьезно.
Не вижу проблем в SVN при объединении веток или коммите в новую.
Я тоже в гите таких проблем не вижу. Но коммит, для меня, это локальное действие.
Я отправляю свой код в сетевой репозиторий, и это — коммит.
Да, в svn это «коммит», т.к., повторюсь, он ущербен от рождения. Как будет работать такой коммит в самолете, например? Мне вот необходимо разделение:
коммит — фиксирование изменений кода
пуш — обновление кода в ветке
И все сразу становится на свои места. А что такое коммит в svn? Только обновление кода. Теперь представим, что необходимо во время разработки переключаться между 3-мя ветками (пусть, для простоты понимания, мы работаем с микросервисами). Как в таком случае быть с svn? Удобно?)
Это вносит путаницу. И лично меня — бесит неимоверно.
Нет. Ни гит, ни svn путаницу не вносят — их вносите вы сами. Вас-же не бесит, что у велосипеда и мотоцикла по 2 колеса, но работают они иначе, да и пользуются ими совсем по разному? А чай вы из тарелки ложкой употребляете? Нет-же, верно? Так и тут — если нет желания, найдется 100500 причин (причем местами довольно смешных) чтобы только себя позлить.
Честно, как только svn научится работать с локальными изменениями, объединением/разделением коммитов (в том числе с возможностью удалить/отредактировать 3-й из 10-и коммит) — тогда я начну воспринимать эту детскую игрушку более-менее серьезно.
Но если вас устраивает svn — используйте. Повторюсь — на вкус и цвет… Мне вот hg совсем не подошел, а svn уже не достаточен — потому и git. Да, в гите тоже есть свои неудобства, свои кривоватости и прочее, но они как-то проще что-ли…
Ну хоть понятно стало, что вы просто не хотите меняться…
Если коммитишь в git, он делает непонятно что, в чём без чтения документации каждый раз не разобраться
Если коммитишь в гит — код именно коммитится. В локальную репу. И это огромный плюс. Позволяет разделять задачу на мелкие подзадачи и выполнять их отдельными коммитами, а в ветку пушится общий результат.
после чего надо выдавать ещё какие-то непонятные команды, чтобы код таки попал в сетевой репозиторий
Это git push не понятный?)) Ну оок…
При работе с проектом, где используется git, у меня очень много времени уходит на борьбу с ним.
Сорри, но в это я не верю. От слова совсем. Скажем так — если вы действительно используете гит, то либо юзаете 5-6 комманд (которые запоминаются через минуты 2-3), либо используете возможности ide/gui/etc. В любом случае, получается точно не сложнее чем с svn. А вот разруливать конфликты в гите значительно удобнее.
Например, на написание скриптов, которые делают с его помощью то, что с SVN делается одной командой.
А можно пример подобного? Мне реально интересно. Не смог вспомнить ни одного случая, когда svn был-бы проще и удобнее. Мне вот часто необходимо слить несколько коммитов в 1, объединить несколько веток в одну, поправить часть кода и запушить в новую ветку, не трогая мастер. Такое проще в svn сделать?
Я не троллю, мне реально интересно. Последний раз, когда трогал svn, последний был версии 1.5 или 1.6, уже точно и не помню. Тогда использование его было целой трагедией. Сейчас многое поменялось?
Хм… Ну я и не заманиваю. На вкус и цвет…
А что касается скорости/юзабельности — лично я на свн уже ни ногой никогда. Использовал лет 5-7 (в основном из-за возможности lock/unlock + исторически).
>Вы просто не умеете его готовить.
Возможно, даже не спорю… Но отвечу в вашем стиле: «Не заманите вы меня на ваш хромой svn, не пытайтесь.»)
Хм… А с чем именно не согласны? С тем, что svn работает медленее? Или с тем, что разруливание конфликтов в snv связан с трагедией, когда идет переименование директорий?
1. Видимо мы разные вещи читаем. Пост от 2013-го года (4 года прошло!!) — 2,2 млрд. хешей в секунду. Не говоря уже о том, что сам md5 взламывают с 2009-го года. Добавим сюда коллизии, готовые rainbow tables и… Не могу найти ни одной причины, чтобы юзать md5 в 2017-м году. Особенно с учетом того, что есть готовые функции, которые делают эту работу намного проще, удобнее и надежнее. За UnitPay спасибо — не буду юзать, раз все так плохо.
2. Ну как объяснить… Ок, давайте попробую так: пилите-пилите проект, разросся он до нескольких гигабайт и тут решили переехать на новую версию php (7-я реально сильно быстрее 5.х). И? Начинаются костыли и рвание волос в одном месте, т.к. использование различается кардинально. Поверьте, не на ровном месте это говорю — проходил на личном опыте, когда надо было обновить проект с историей более 10 лет. Это только одна из причин, их можно легко набрать пару десятков.
4. видимо не внимательно прочел, прошу прощения.
5. Эмм…
>Это позволяет записывать в лог каждое изменение IP пользователя.
Как это связано с аутентификацией? Логи — это совсем другое. Логируйте смену ip, в чем проблема-то? Но ip точно не должно быть частью авторизации/аутентификации.
6. Ммм… Давно не трогал, решил посмотреть — может что изменилось… Ан нет… god-объект Application, по всему коду синглтоны, за такое руки оторвал-бы, тут «на всякий случай»? И это я пару файлов наугад ткнул. По поводу вордпресса — я вроде не предлагал учится на его коде).
>К SVN какие претензии? :)
Их слишком много) От тормозной работы (т.к. только diff, а не полная копия), до stash и удобства разруливания конфликтов.
На самом деле, всё ужасно от слова «совсем».
1. md5. даже не sha1. при том, что давным-давно практически во всех уголках инета рекомендуются спец.функции. Раньше был crypt, сейчас очень рекомендуется использовать password_*.
2. mysql. ну про это выше неоднократно написали.
3. sql-inj. тоже написали.
4. хранение пароля в сесии (не важно, php- или своей). Что-за бред? Почему в базе храним хешированный пароль, а в сесии нет? Храним хешированный с другой солью + подпись для проверки целостности данных. Эти 2 простых приема дадут больше пользы, чем весь код в посте.
5. Привязка к ip — это жесть. Вы часто приводите в пример vk, но я уверен, что там это реализовано иначе — проверям, сменилась-ли страна/регион/город с момента последнего обращения, а не смену ip. Не должна аутентификация быть привязана к чему-то, кроме самого пользователя.
6. Никогда(!) и никому(!) не говорите ничего про джумлу. Хуже кода, лично я, не видел ни разу.
И да, хотите сделать что-то правильно — хотя-бы(!) изучите то, что сделали и проверили в работе другие люди.
P.S.: отдельная жесть — php 5.3, svn. Тут даже не знаю что сказать…
Абсолютно не важно, сколько строк надо добавить — одну или пару сотен. Важен факт того, что это можно (и, имхо, необходимо) автоматизировать. Фреймворки я использую для того, чтобы избавиться от рутинных операций. Думаю, большинство также. В данном случае фреймворк заставляет (и это именно так) думать не про решение задачи, а про использование самого фреймворка.
вы всегда можете перегрузить 1 метод в 3 строки
Да, конечно могу. Как и многое другое. Но, как и любой нормальный программист, я не люблю делать что-то рутинное и не относящееся к решению конкретной задачи. Если для использования какой-то библиотеки или фреймворка мне необходимо делать «лишние» (читайте — не относящиеся к решению задачи) действия — скорее всего библиотека или фреймворк не подходят для текущей задачи.
Далее… Подход, при котором разработчик чуть-ли не в ручную контролирует подключение каждого файла подходит для энтерпрайза, когда каждый дополнительный элемент должен быть одобрен каждым из десятка начальников и только после этого может быть подключен к основному коду. Но «фея» из другой области. Она не может тягаться с симфони или зендом, она для мелких и средне-мелких задач — для них жизнено необходима автоматизация всего, что только возможно. Ни один человек в здравом уме не будет писать блог на микросервисной архитектуре, верно? Так и тут — не надо навязывать принципы из другой области, имхо.
Ну да, ну да… Их использование без лишней работы невозможно, правильно я понял?
Зависит уже от вашего уровня. Зачем вам фреймворк совсем? Поставьте Wordpress п программируйте формы мышкой =)
Именно так и сделаю, если потребуется простенький блог, например. А фреймворки использую для других задач. Троллинг, как способ привлечения пользователя — интересный способ, но не действенный. Уж лучше останусь на Phalcon/Zend, в таком случае. Всего доброго.
Вас не смущает, что у других подобных проблем не возникает?))))))))
Вот svn в качестве молотка отвратителен — сбитый боек, треснутая ручка, не работает когда не подключен к интернету, не работает, когда нужен сразу нескольким трудягам — один ручку забрал, другой боек и ни у одного не получается забить гвоздь.
А когда им обоим говорят — вот, возьмите бесплатно каждый по новому молотку с удобной ручкой, говорят нет, у новых молотков ручка слишком удобная, не привычно, тяжело себе по пальцам ударить…
Это разные действия).
Прятать? Вы о чем? Я не хочу, чтобы недоделанная задача повлияла на пару десятков других разработчиков. В svn это сложно.
А многим нужны именно по отдельности. И желание появилось не на ровном месте.
Я уже приводил выше: решение одной большой задачи итерационно, разбивая ее на множество мелких.
Можно я не буду на это отвечать?)))
И это хорошо! Чем меньше плохого инструмента в обращении — тем лучше.
Мне вот не нравится drupal, но это не означает что он плохой, верно? Хотя нет — для меня он ужасен.
На вкус и цвет… Если-бы svn был удобен — с него не убегали бы. А с него бегут. Не только в git, но и в hg и в bazaar. Бегут именно по причине того, что svn не дает работать.
Думаю, на этом и закончим. Мне уже понятно, что у вас чисто эмоциональная неприязнь инструмента.
Не нравится мне он, но в вашем случае проблема точно не в нем и не в троллинге ;)
Например? Мне кажется — вы сейчас сильно лукавите. Если проблема в коммите — у вас проблема с настройками и/или правами. Если в пуше — значит у вас конфликт, который легко разруливается. А ваш «рецепт» похож на мазохизм, из серии «пусть мне будет плохо, но я так хочу»…
А как в svn сделать локальные репы?
Круто. git commit & git push. В чем проблема? А как сделать в svn, чтобы в сетевую репу не попали куча разных коммитов, а попал только один, финальный?
Верно. Потому (только не злитесь) что svn ущербен. На большее, кроме как получить/отдать, он от рождения не способен. Да, в простых случаях этого хватает. Но не всем и не всегда.
Чтобы в истории видеть 1 коммит = 1 задаче, но при этом в разработке дробить эту задачу на 100500 мелких и решать их отдельно разными коммитами.
Ну так вот она проблема, а не в гите ;). Ну серьезно.
Я тоже в гите таких проблем не вижу. Но коммит, для меня, это локальное действие.
Да, в svn это «коммит», т.к., повторюсь, он ущербен от рождения. Как будет работать такой коммит в самолете, например? Мне вот необходимо разделение:
коммит — фиксирование изменений кода
пуш — обновление кода в ветке
И все сразу становится на свои места. А что такое коммит в svn? Только обновление кода. Теперь представим, что необходимо во время разработки переключаться между 3-мя ветками (пусть, для простоты понимания, мы работаем с микросервисами). Как в таком случае быть с svn? Удобно?)
Нет. Ни гит, ни svn путаницу не вносят — их вносите вы сами. Вас-же не бесит, что у велосипеда и мотоцикла по 2 колеса, но работают они иначе, да и пользуются ими совсем по разному? А чай вы из тарелки ложкой употребляете? Нет-же, верно? Так и тут — если нет желания, найдется 100500 причин (причем местами довольно смешных) чтобы только себя позлить.
Честно, как только svn научится работать с локальными изменениями, объединением/разделением коммитов (в том числе с возможностью удалить/отредактировать 3-й из 10-и коммит) — тогда я начну воспринимать эту детскую игрушку более-менее серьезно.
Но если вас устраивает svn — используйте. Повторюсь — на вкус и цвет… Мне вот hg совсем не подошел, а svn уже не достаточен — потому и git. Да, в гите тоже есть свои неудобства, свои кривоватости и прочее, но они как-то проще что-ли…
Если коммитишь в гит — код именно коммитится. В локальную репу. И это огромный плюс. Позволяет разделять задачу на мелкие подзадачи и выполнять их отдельными коммитами, а в ветку пушится общий результат.
Это git push не понятный?)) Ну оок…
Сорри, но в это я не верю. От слова совсем. Скажем так — если вы действительно используете гит, то либо юзаете 5-6 комманд (которые запоминаются через минуты 2-3), либо используете возможности ide/gui/etc. В любом случае, получается точно не сложнее чем с svn. А вот разруливать конфликты в гите значительно удобнее.
А можно пример подобного? Мне реально интересно. Не смог вспомнить ни одного случая, когда svn был-бы проще и удобнее. Мне вот часто необходимо слить несколько коммитов в 1, объединить несколько веток в одну, поправить часть кода и запушить в новую ветку, не трогая мастер. Такое проще в svn сделать?
Я не троллю, мне реально интересно. Последний раз, когда трогал svn, последний был версии 1.5 или 1.6, уже точно и не помню. Тогда использование его было целой трагедией. Сейчас многое поменялось?
А что касается скорости/юзабельности — лично я на свн уже ни ногой никогда. Использовал лет 5-7 (в основном из-за возможности lock/unlock + исторически).
>Вы просто не умеете его готовить.
Возможно, даже не спорю… Но отвечу в вашем стиле: «Не заманите вы меня на ваш хромой svn, не пытайтесь.»)
А насчет ссылки… Обсуждалось-же уже на хабре. Как говорится — «ложь и провокация»)))
2. Ну как объяснить… Ок, давайте попробую так: пилите-пилите проект, разросся он до нескольких гигабайт и тут решили переехать на новую версию php (7-я реально сильно быстрее 5.х). И? Начинаются костыли и рвание волос в одном месте, т.к. использование различается кардинально. Поверьте, не на ровном месте это говорю — проходил на личном опыте, когда надо было обновить проект с историей более 10 лет. Это только одна из причин, их можно легко набрать пару десятков.
4. видимо не внимательно прочел, прошу прощения.
5. Эмм…
>Это позволяет записывать в лог каждое изменение IP пользователя.
Как это связано с аутентификацией? Логи — это совсем другое. Логируйте смену ip, в чем проблема-то? Но ip точно не должно быть частью авторизации/аутентификации.
6. Ммм… Давно не трогал, решил посмотреть — может что изменилось… Ан нет… god-объект Application, по всему коду синглтоны, за такое руки оторвал-бы, тут «на всякий случай»? И это я пару файлов наугад ткнул. По поводу вордпресса — я вроде не предлагал учится на его коде).
>К SVN какие претензии? :)
Их слишком много) От тормозной работы (т.к. только diff, а не полная копия), до stash и удобства разруливания конфликтов.
1. md5. даже не sha1. при том, что давным-давно практически во всех уголках инета рекомендуются спец.функции. Раньше был crypt, сейчас очень рекомендуется использовать password_*.
2. mysql. ну про это выше неоднократно написали.
3. sql-inj. тоже написали.
4. хранение пароля в сесии (не важно, php- или своей). Что-за бред? Почему в базе храним хешированный пароль, а в сесии нет? Храним хешированный с другой солью + подпись для проверки целостности данных. Эти 2 простых приема дадут больше пользы, чем весь код в посте.
5. Привязка к ip — это жесть. Вы часто приводите в пример vk, но я уверен, что там это реализовано иначе — проверям, сменилась-ли страна/регион/город с момента последнего обращения, а не смену ip. Не должна аутентификация быть привязана к чему-то, кроме самого пользователя.
6. Никогда(!) и никому(!) не говорите ничего про джумлу. Хуже кода, лично я, не видел ни разу.
И да, хотите сделать что-то правильно — хотя-бы(!) изучите то, что сделали и проверили в работе другие люди.
P.S.: отдельная жесть — php 5.3, svn. Тут даже не знаю что сказать…
/system/ — это от корня, потому и не работает ;)
Абсолютно не важно, сколько строк надо добавить — одну или пару сотен. Важен факт того, что это можно (и, имхо, необходимо) автоматизировать. Фреймворки я использую для того, чтобы избавиться от рутинных операций. Думаю, большинство также. В данном случае фреймворк заставляет (и это именно так) думать не про решение задачи, а про использование самого фреймворка.
Да, конечно могу. Как и многое другое. Но, как и любой нормальный программист, я не люблю делать что-то рутинное и не относящееся к решению конкретной задачи. Если для использования какой-то библиотеки или фреймворка мне необходимо делать «лишние» (читайте — не относящиеся к решению задачи) действия — скорее всего библиотека или фреймворк не подходят для текущей задачи.
Далее… Подход, при котором разработчик чуть-ли не в ручную контролирует подключение каждого файла подходит для энтерпрайза, когда каждый дополнительный элемент должен быть одобрен каждым из десятка начальников и только после этого может быть подключен к основному коду. Но «фея» из другой области. Она не может тягаться с симфони или зендом, она для мелких и средне-мелких задач — для них жизнено необходима автоматизация всего, что только возможно. Ни один человек в здравом уме не будет писать блог на микросервисной архитектуре, верно? Так и тут — не надо навязывать принципы из другой области, имхо.
Ну вот как-то так…
Ну да, ну да… Их использование без лишней работы невозможно, правильно я понял?
Именно так и сделаю, если потребуется простенький блог, например. А фреймворки использую для других задач. Троллинг, как способ привлечения пользователя — интересный способ, но не действенный. Уж лучше останусь на Phalcon/Zend, в таком случае. Всего доброго.
В чем заключается «более правильность»? Я честно не вижу в этом ни правильности, ни удобства.
Путем создания дополнительной работы? Оно мне надо?
В целом, пример не понравился. Сделать тоже самое на любом другом фреймворке — чуть-ли не 1-в-1 кода (возможно в каких-то даже поменьше будет).
>Вы будете использовать эти слова, когда будете рассказывать сегодня другу показывая, что ваши новые наушники умеют работать через bluetooth?
Если человек занимается продажей этих наушников — почему нет? Интересно как «будущему стартаперу» ).
>Но да, в вашем случае можно руку и лютому врагу пожать ради прибыли
Сорри, но вы ругаетесь на инструменты гугл, но с помощью них зарабатываете деньги. Разве это не одно и то же?