Лучший способ предотвратить изменения на ответвлении с Подрывной деятельностью

Question

Лучший способ предотвратить изменения на ответвлении с Подрывной деятельностью

Работающий хак - добавить pm.sendRequest с данными из второго теста на вкладку «Тесты» 1-го теста. В этом случае 2-й тест не выполняется в целом, но подарки собираются. Это не лучшее решение, но оно работает.

let jsonData = pm.response.json();

let giftsArray = [];

_.each(pm.response.json().gifts, (item) => {
    giftsArray.push(item.id);
});

pm.sendRequest({
    url: 'http://url/api/gifts/collect',
    method: 'POST',
    header: {
        'Content-type': 'application/json',
        'Host': 'url',
        'accept-encoding': 'gzip, deflate',
        'Connection': 'keep-alive'
    },
    body: {
        mode: 'raw',
        raw: JSON.stringify({'api_token': '48696295110ba1e8f9937820dc9b6626', 'user_id': '100650741100901', 'gift_ids': giftsArray, 'version': '6.0.0'})
    }
}, function (err, res) {
console.log(res);
});

10

svn branch

задан Garry Shutler 22 April 2009 в 09:36

5 ответов

Другие вопросы по тегам:

svn branch

Похожие вопросы:

score 3 · Answer 1

Не тратьте свое время на попытки предотвратить это. Если разработчик вносит изменения в неправильную ветку, просто отмените их, если это произойдет, и обязательно сообщите об этом разработчику.

... hack hack hack ... on branch
$ svn ci -m "Feature-1337 implemented" branch
Revision 12345

...oops...

$ svn merge -c12345 branch trunk
$ svn ci -m "moved Feature-1337 from branch to trunk" trunk
$ svn merge -c-12345 branch branch
$ svn ci -m "reverted Feature-1337 on branch. it's intended only for trunk" branch

score 5 · Answer 2

Я не знаю ни одного встроенного способа активно предотвратить это. Вы, вероятно, могли бы сделать это, используя «pre-hook репозитория». Это небольшая программа, которая запускается перед каждым коммитом. Если это не удается, фиксация в целом не выполняется. См. главу о хуках в книге Subversion.

Ваш скрипт хуков будет проверять путь, который должен быть зафиксирован, и запрещать его. Это может помочь: http://metacpan.org/pod/SVN::Hooks

Тем не менее, вы действительно уверены, что хотите это сделать?

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

score 6 · Answer 3

Почему у всех проверяется вся иерархия SVN? Было бы гораздо меньше ошибок, если бы все проверили только ствол / ветви, над которыми они работают. Вы не можете проверить что-то в ветке, которую вы не проверили.

Я могу поддержать практику, чтобы пометить релиз, как упомянуто Раззи .

score 3 · Answer 4

Я думаю, что было бы неплохо удалить «ветки релиза» и вместо них сделать их тегом, поскольку это является целью тега.

Это на самом деле не решает проблему, хотя может предотвратить больше таких аварий, так как вы никогда не должны работать в теге. И я согласен с брендом, если это все-таки произойдет, отмените эти изменения и пните разработчика: -)

score 3 · Answer 5

Почему вы используете ветки в качестве тегов? Я бы посоветовал:

Локальные стандарты разработки (т.е. не фиксируйте там, где мы просим вас не фиксировать)
Повышение квалификации по Subversion (т.е. почему разработчики проверяют весь репозиторий?)
Используйте структуру тегов для чего это было предназначено

При этом, и предполагая, что иерархия вашего репозитория представлена следующим образом:

* repo
  - tags
  - trunk
  - branches

Хотя книга SVN выступает против детального контроля таким образом, вы также можете использовать svn_access_file , чтобы предотвратить какие-либо коммиты в ветках? Например:

[repo:/]
@developers = rw

[repo:/branches]
@developers = r
@rel_engineers = rw

Если вы хотите, чтобы разработчики могли создавать ветки, вам придется спускаться в каждую ветвь индивидуально (что возвращает нас к исходной посылке SVN Book, в которой в первую очередь советуют не использовать этот метод).