Как я мог бы обработать версии разработки пакетов Python, не полагаясь на SCM?
Если Вы сделали 1 регистрацию, и Вы просто хотите отменить ее, который имеет changeset # связанный с нею. Сделайте историю на рассматриваемой папке для наблюдения плохого changeset. Откройте его для наблюдения деталей (все измененные файлы, и т.д.).
я полагаю, что можно восстановить или отменить changeset с того экрана, но моя Visual Studio просто отказала, когда я пытался сделать это. / вздох - я определенно совместно использую Вашу боль.
, Где делают меня downmod TFS на этом сайте?
4 ответа
I meant to mention that the solution I had considered before asking was to put up a Pinax PyPI and make development releases on it. We could put up an instance of chishop. We are already using pip's --find-links to point at pypi.pinaxproject.com for packages we've had to release ourselves.
Could you handle this using the "==dev" version specifier? If the distribution's page on PyPI includes a link to a .tgz of the current dev version (such as both github and bitbucket provide automatically) and you append "#egg=project_name-dev" to the link, both easy_install and pip will use that .tgz if ==dev is requested.
This doesn't allow you to pin to anything more specific than "most recent tip/head", but in a lot of cases that might be good enough?
Большинство дистрибьюторов с открытым исходным кодом (Debians, Ubuntu, MacPorts и др.) Используют какой-то механизм управления исправлениями. Что-то вроде: импортируйте базовый исходный код для каждого выпущенного пакета, как tar-шар или как снимок SCM. Затем управляйте любыми необходимыми модификациями поверх него с помощью диспетчера исправлений, например quilt или Mercurial's Queues . Затем свяжите каждый внешний пакет со всеми примененными исправлениями в согласованном формате. Или укажите URL-адреса базовых пакетов и URL-адреса отдельных исправлений и примените их во время установки. По сути, это то, что делает MacPorts .
РЕДАКТИРОВАТЬ: Чтобы сделать еще один шаг вперед, вы можете затем управлять версиями набора исправлений для всех внешних пакетов и сделать , что доступным как единица. Который' Это довольно просто сделать с Mercurial Queues. Затем вы упростили задачу до простой публикации одного набора исправлений с использованием одной системы SCM, при этом исправления применялись локально, как указано выше, или были доступны разработчикам для извлечения и применения к своим копиям пакетов базового выпуска.
EDIT: I am not sure I am reading your question correctly so the following may not answer your question directly.
Something I've considered, but haven't tested, is using pip's freeze bundle feature. Perhaps using that and distributing the bundle with Pinax would work? My only concern would be how different OS's are handled. For example, I've never used pip on Windows, so I wouldn't know how a bundle would interact there.
The full idea I hope to try is creating a paver script that controls management of the bundles, making it easy for users to upgrade to newer versions. This would require a bit of scaffolding though.
One other option may be you keeping a mirror of the apps you don't control, in a consistent vcs, and then distributing your mirrored versions. This would take away the need for "everyone" to have many different programs installed.
Other than that, it seems the only real solution is what you guys are doing, there isn't a hassle-free way that I've been able to find.