Що стосується розміщення ваших особистих проектів, що виділяються, чи виділяється одна послуга та структура проекту? [зачинено]

Я переглядаю Google Code, SourceForge, BitBucket та GitHub, оскільки вони, здається, є великими гравцями. Тепер я ще не розбив усі функції, які вони надають, але я дійсно шукаю місце для розміщення різного коду, який я пишу (мої рішення для Project Euler, код, який я можу написати для Code Golf / Програмування головоломок Обмін стеками тощо) в централізованому місці.

Отже, моє перше запитання: Чи є така ситуація, як ця ситуація, серед інших?

Після того, як я обрав службу, мені потрібно вибрати, як я буду розповсюджувати код. Є кілька варіантів, які я бачу для налаштування сховищ та проектів. Одне сховище може вміщувати будь-яку кількість проектів - наприклад, я міг би мати сховище "Проект Euler Solutions Project Tom" для всіх моїх різних рішень для Project Euler, з проектами для кожної мови та середовища в каталогах цього репозиторію, іншим сховищем для моїх різноманітних рішень Code Kata тощо. Або я можу розбити щось подібне за мовою (мати рішення Project Euler в Python в одному сховищі, PE-рішення в Java в іншому сховищі та рішення Code C ++ в третьому сховищі).

Моє друге питання: Чи існують якісь обмеження чи умови, які визначають, як слід ділитися зразками коду, які ви вирішили зробити відкритими, особливо з точки зору того, як ви створюєте свої сховища? Думаю, що це може бути продиктовано службою, яку ви обираєте (виходячи з конвенцій громади).

Bitbucket.

Вони надають чудовий сервіс, приватні сховища у своєму безкоштовному пакеті (плюс необмежену кількість публічних) і досить чуйні у своєму трекері випуску.

Те саме, мінус безкоштовні приватні сховища, стосується і Github, але я дуже не люблю git. Це особисті переваги, я не виступаю проти git, якщо з якоїсь дивної причини ви віддаєте перевагу над hg, то Github - цілком вірний вибір.

Щодо того, як організувати репост, не змішуй мови, якщо ти можеш цього уникнути. Більшість IDE побудовані на основі припущення, що проект побудований на одній мові (за винятком веб-проектів, де очікується комбінація мови + html, css & js). Я не кажу, що IDE не зможе впоратися, просто такі функції, як завершення коду, будуть трохи повільнішими, оскільки IDE доведеться завантажувати дані про те, як обробляти кожну мову.

Якщо ваші репортажі є загальнодоступними (отже, необмеженими), я б пішов на репо за кожну мову за схемою проекту, тобто "euler_cpp", "euler_python" тощо. Насправді не важливо, яку службу ви обираєте, як організуєте репост повністю залежить від вас.

Що стосується структури папок, для рішень проекту euler:

• Папка на проблему, якщо ви плануєте мати різні рішення однієї проблеми
• Файл за проблемою, для одиничних рішень

Виберіть те, що застосовується, і дотримуйтесь його, якщо для однієї проблеми у вас є більше одного рішення, виберіть першу структуру, навіть якщо у вас немає другого рішення для будь-якої іншої проблеми.

оновлення:

Один файл на кожну проблему пропонується лише тоді, коли вона фактично застосовна і запропонована як потенційна схема для вирішення проблем проекту euler, оскільки це єдиний проект, який вказаний у питанні.

Відповідно до коментаря btilly, я додаю, що краща / більш природна структура повинна визначатися для кожної мови, оскільки кожна мова та / або платформа мають власні конвенції та практики щодо файлів і папок.

Ви забули один варіант - розміщення власного сховища. Дійсно, це був єдиний спосіб літати до недавнього часу.

Якби мені довелося сьогодні використовувати один, я б вибрав бітбукет головним чином тому, що вони дозволяють приватні репости та меркурійські породи.

Після використання Google Code, SourceForge та GitHub в різні моменти часу, я б сказав, що GitHub набагато краще, ніж інші два:

• Зосереджується повністю на власне роботі зі створення та спільного використання коду.
• Обробка проблем увімкнена за замовчуванням і не просто проста у використанні, але добре пов’язана як з кодовим, так і з потягним запитом.
• Довідка для початківців є прекрасною, наприклад, покрокові інструкції щодо початку роботи із сховищем та для обробки запитів на виклик.
• Не призначений для двійкового розподілу; з цим краще впоратися на спеціалізованих сайтах, таких як PyPI.
• Прості вікі замість того, щоб розробляти власну веб-сторінку з нуля.
• Відмінна підтримка каналу - єдиний канал для всього, що мені цікаво.
• Неформальне та, таким чином, читабельне спілкування.
• Дуже активний розвиток нових функцій.

Мої особисті проекти не дуже великі (багато тексту, без графіки), тому у мене є сховища Mercurial з майстрами в DropBox. Це швидкий спосіб розпочати резервну копію (якщо DropBox піде, у мене все ще є копія сховища на кожному комп'ютері, який я маю) та переносності.

Якщо припустити, що у мене є проект, який доходить до того, коли я хочу його поширити, я завжди можу перемістити його в Bitbucket для більшої наочності. Це не включає код для рішень проекту Euler.