Как делают repos (SVN, МЕРЗАВЕЦ) работа?

1 && 2)
SVN: Когда B попытается сделать коммит, возникнет ошибка, говорящая о том, что у него нет последней версии кода. Ему нужно будет выполнить svn update и объединить изменения, сделанные человеком A, со своими собственными. Смотрите Как разрешить конфликты SVN.

GIT: Поскольку у вас есть собственный локальный репозиторий, вы можете свободно делать коммиты. Когда вы отправляете (git push) свои изменения в удаленный репозиторий, вам приходится объединяться. См. Разрешение конфликтов слияния в GIT

3) Ветвление Wiki Page

В качестве дополнительного примечания: если вы планируете полностью переписать файл, часто вежливо, чтобы члены команды, работающие над той же функцией, знали, чтобы избежать боли -in-the-tuckus сливается.

1 и 2 зависят от используемого вами контроля исходных текстов, но есть некий вид слияния, который должен быть выполнен. А ветви - это версии кода, которые были форкнуты из ствола (основной версии).

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

Я бы рекомендовал прочитать этот документ, он довольно хорошо объясняет различные возможные рабочие процессы централизованных и децентрализованных (гораздо лучших) систем контроля версий: http://wiki.bazaar.canonical.com/Workflows

Для этого можно использовать XStream . Вы можете работать без аннотаций, например:

XStream xstream = new XStream();
XStream xstream = new XStream(new DomDriver());
xstream.alias("person", Person.class);
xstream.alias("phonenumber", PhoneNumber.class);

надеюсь, что это поможет

EDIT: создать другой экземпляр XStream для другого вывода

Person demo = new Person("Chris");

XStream xStream = new XStream();
xStream.alias("person", Person.class);
System.out.println(xStream.toXML(demo));

XStream xStream2 = new XStream();
xStream2.alias("dev", Person.class);
System.out.println(xStream2.toXML(demo));

output:

<person>
  <name>Chris</name>
</person>
<dev>
  <name>Chris</name>
</dev>

1. Человек B знает, что при запуске обновления или попытке фиксации на сервере происходит изменение.
2. Этот процесс называется слиянием. Большинство систем очень умны и пытаются объединиться для вас. Однако иногда возникают конфликты, и в этом случае человека информируют и просят разрешить конфликт. Это произойдет, если лица A и B изменят одну и ту же строку кода в одном и том же файле.

Хорошо для Git, вы в основном копируете весь проект из «главной» ветви в свою собственную личную ветвь, где вы можете изменять и вносить изменения в свою личную ветвь, и если вы думаете, что это хорошо, вы можете объединить свою личную ветвь с главной.

Думаю, вам нужно узнать больше о SCM-подобных инструментах. Вы сомневаетесь, что эти операции очень распространены в среде разработки. Вот мои предложения о книгах по SVN и Git:

• Практическая Subversion, второе издание
• Pragmatic Version Control: Использование Subversion
• Управление версиями с Git: мощные инструменты и методы для совместной разработки программного обеспечения
• Pro Git
• ] Шаблоны управления конфигурацией программного обеспечения: эффективная совместная работа, практическая интеграция

Хорошее прочтение: -)

То, что я говорю ниже, действительно для svn, поскольку git или mercurial немного отличаются (я бы сказал, проще).

1) Человек B должен обновить и объединить изменения в своей локальной копии, прежде чем зафиксировать -ing (она также может просто проверить ] если есть изменения). Если он просто попытается зафиксировать , она получит сообщение о том, что его локальная копия svn устарела.

2) У человека B некоторые проблемы, так как слияние не будет простым (SVN не будет управлять им автоматически, это вызовет конфликт ) ... если это действительно слишком сложно, B придется думаю, она снова изменится.

У этой проблемы нет решения. Некоторые системы управления версиями допускают какую-то блокировку, но это порождает другие проблемы (файл может оставаться заблокированным в течение длительного времени, и никто, кроме шкафчика, не может работать с ним в промежутке, даже для изменений, которые могут легко объединиться). Просто делайте почаще небольшие изменения и разговаривайте с другими кодировщиками (посредством реальной встречи, IRC, электронной почты или любым другим способом), чтобы этого не произошло.

3) Ветвление действительно полезно с распределенной системой контроля версий. Он существует в svn в искалеченной версии. Просто вы делаете копию текущего каталога текущего репо в другом каталоге, два каталога развиваются каждый со своим собственным жизненным циклом (скажем, один заморожен только для исправлений ошибок, а другой для новых функций и изменений), и в какой-то момент вы пытаетесь чтобы объединить изменения между двумя репозиториями, например, попытаться перенести исправление ошибок в ветку новых функций или перенести некоторые новые функции из новой ветки в старую.

Я думаю, что ваша самая большая проблема не в различиях в производительности или возможностях. Думаю, дело дойдет до документации. MSDN, вероятно, будет предоставлять функции на обоих языках, но большинство записей блога и т. д. будут в c #. Эти сообщения могут предложить реальные рекомендации по передовым практикам, советы и рекомендации, а также множество другой информации, на которую вы будете опираться в вашей практике разработки и большинство будет в c #.

Для сохранения:

NSMutableArray *array = [[NSMutableArray alloc] init];
[array writeToFile:[@"/path/to/file.plist"] atomically: TRUE];

Для получения:

NSMutableArray *array = [[NSMutableArray arrayWithContentsOfFile:[@"/path/to/file.plist"]] retain];

1. В SVN B будет знать об изменении A, когда B попытается обновить его копию или вернуть. В GIT он узнает, когда пытается перенести изменения в свой локальный репозиторий или перенести их в главный. (На самом деле, я не знаю GIT, поэтому я продолжаю то, что я знаю о Mercurial.)

2. В таком случае, у вас есть проблемы независимо от того, что вы делаете, и независимо от того, какой контроль версий вы используете. Единственное преимущество блокировки VCS заключается в том, что A или B будут знать, что другой работает над программой, но это может быть сделано другими способами. Правильно сделать так, чтобы все знали о происходящих больших изменениях и координировали свои действия оттуда. Однако на практике это происходит нечасто. В большинстве случаев, если A и B работают над файлом, их изменения легко и правильно объединяются.

3. Ветвь - это другая «последняя версия», поэтому не всем приходится постоянно работать над одной и той же линией разработки кода.

Одним из способов использования ветвей является разработка функции или чего-то еще, которая займет длительное время, без путаницы с основной линией с частичными обязательствами.

Другой задачей является поддержка версий выпуска. Вместо доставки клиенту последней версии (которая может не полностью работать и может содержать функции, которые клиент не оплатил), чтобы исправить ошибку, исправить ошибку в ветви выпуска и отправить ее. Это намного менее разрушительно для клиента. (Просто убедитесь, что ошибка исправлена на головной версии, также)

1. Человек B знает, что есть изменение, когда он запускает обновление или пытается зафиксировать на сервере.
2. Этот процесс называется слиянием. Большинство систем очень умны и пытаются выполнить слияние за вас. Однако иногда возникают конфликты, и в этом случае человеку сообщают об этом и просят разрешить конфликт. Это произойдет, если человек A и B изменяют одну и ту же строку кода в одном и том же файле.

1. Человек Б может сделать проверку модификаций из SVN. Я уверен, что существует инструмент, который проверяет изменения каждые несколько минут и предупреждает вас о них.
2. Они объединяют изменения вместе.
3. По сути, когда вы делаете разрушающее изменение, вы хотите взять свою рабочую копию и изменить её вне рабочей копии (trunk) всех остальных. Поэтому вы создаете ответвление. Таким образом, другие люди могут работать над веткой, если захотят, но в основном они могут работать в стволе, не беспокоясь об этом, а затем вы сливаете ветку, когда закончите с этим ломающим изменением

2) На этом этапе B должен объединить изменения, внесенные A, со своими собственными изменениями. Если они работали с разными частями кода в файле, инструмент управления версиями обычно может делать это автоматически. Если их изменения совпадают, это может стать довольно одиозной задачей, но это случается редко.

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

Я не могу рекомендовать книгу Эрика Синка Source Control HOWTO. Она даст вам ответы на вопросы, которые вы ищете, и хорошее понимание контроля исходных текстов в целом.