Заборонені папки в Subversion

Що значить "перешкода" означає, якщо ви намагаєтеся зайти в Subversion? Я бачу дві папки червоного кольору з текстовим статусом "перешкоджені". Я не бачу, що це означає ніде в документах.

Коли я пробую cleanupкоманду, я отримую "ім'я папки - це не робочий каталог". Це папка, яку я щойно створив у VS, і коли я намагаюся додати її до Subversion, вона дає мені цю помилку. Усі інші папки - це добре.

це відбувається, коли ви видалили або перемістили підкаталоги .svn (не переходячи через команди SVN), тому SVN має зіпсований вигляд робочої копії.

Спробуйте спочатку очистити, і якщо це не вирішить проблему, відновіть (або оновіть) каталог, щоб відновити папки .svn підкаталогу.

Не знаючи, що це спричиняє, рішенням може бути експорт робочої копії (всієї каси, яка є у вас на місцевому рівні) кудись інше.

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

Закінчивши, перевірте чисту робочу копію, а потім опустіть експортовану резервну копію, яку ви маєте на верхній частині. Дуже важливо, щоб у резервній копії не було папок .svn.

Я бачив ці помилки раніше, коли люди перевіряли робочі копії всередині інших робочих копій або що-небудь інше, що псує записи .svn.

Виникла та сама проблема та виправлено її так:

• перейменований на перешкод
• створив dir з оригінальною назвою у SVN (наприклад, svn mkdir)
• оновив батьківську папку, тому щойно створений редактор з'явився в моїй робочій копії
• скопіював файли з перешкод до новоствореного режиму і зафіксував їх

Якщо ви перебуваєте в системі * nix, переконайтеся, що ви не створили файл, додайте його до SVN, а потім видаліть, замінивши його однойменною папкою. Це не допомагає ОП, але, сподіваємось, це врятує когось купу стресу.

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

(Перефразоване з файлу довідки клієнта Tortoise SVN)

Ніщо не працювало для мене, тому я зробив наступне:

• експортується з неперевершеними файлами в нове місце
• перейменовано на існуючу папку
• перемістив папку з місця експорту в проекті
• перейменовано на нову папку
• додати, вчинити
• видалено стару, перейменовану папку
• перейменовано на нову папку
• вчинити

Існують різні варіації сценарію, які можуть спричинити цю ситуацію. Ось один із прикладів:

Я закінчився з! позначте в каталозі, який був перейменований з www у www_a без використання команди "svn rename":

1. Перейменуйте поточний каталог, який має оригінальну назву, наприклад, у www_b
2. Перейменуйте www_a назад на www
3. Переконайтеся, що ви робите "оновлення svn" або "повернення до svn" всередині каталогу www
4. Видаліть оновлений веб-каталог без використання "svn delete"
5. Перейдіть у батьківський каталог та випустіть 'svn update'
6. Це відновить вихідний www-каталог
7. Цього разу використовуйте 'svn rename' для перейменування www у www_a
8. Перейменуйте www_b назад на www
9. Використовуйте 'svn add', щоб додати його до сховища

Ви повинні отримати правильний робочий каталог svn в цей момент. І дізнайтеся щось або дві про те, як вирішити плутанину каталогу спн.

З цим питанням стикалися на машині Windows.

Я перевірив каталог, перш ніж перевірити весь проект, до якого він належав. Це спричинило для мене «перешкоду».

Я просто видалив цю папку і запустив оновлення з root (цієї папки). Це добре працювало.

Такі команди, як очищення тощо, для мене не працювали.

Деякі обережні слова:

1. Це дорого, якщо папка велика.
2. Це призведе до втрати всіх змін, якщо такі є.

Всього найкращого.

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

Кроки до відтворення:

1. Оформити замовлення

   svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir
   

2. Перевірте, чи ваш каталог добре

   cd plugin_dir
   svn st -u
   

   Вихід повинен бути

   Status against revision: 1234
   

3. Створіть симпосилання (що показує проблему)

   cd ..
   mklink /d link_dir plugin_dir
   cd link_dir
   svn st -u
   

   Вихід буде

   ~           1234  .
   Status against revision: 1234
   

Я зіткнувся з цією проблемою, коли вставляв папку з підкаталогами в свою робочу копію за допомогою мого FTP-клієнта - я знав, що перекрутився, як тільки натиснув кнопку передачі ... небезпеки робочого шляху занадто пізно.

Я спробував усі запропоновані вище пропозиції та інші знайдені в Інтернеті безрезультатно. Кожна опція викликала помилку, що мій каталог був заблокований, і операцію неможливо було виконати.

Я зайшов у свою копію Time Machine, відновив каталог і добре зайшов. Я очистив робочу копію як запобіжний стан, оновив свої файли належним чином і повернувся до справи.

У нас часто є кілька гілок одночасно на ходу, щоб врятувати мене перемиканням чи возитися з конфігурацією IIS, я перевіряю кожну гілку в окрему папку. Потім я використовую посилання каталогів, щоб з'єднати ці папки до основного шляху, налаштованого в IIS.

Тож для мене пов'язаний каталог завжди має жовтий вигук і позначений як перешкода. Я вважаю, це тому, що це було технічно створено / переміщено за межі SVN.

Я отримую цей "перешкодний" статус у каталогах, коли я оновлюю CMS (WordPress або Drupal) через веб-інтерфейс - додаток не знає, що його код - це фактично підривна робоча копія, тому при оновленні плагіна видаляє цей плагін каталог (включаючи .svn каталог) і потрапляє в новий каталог з нової версії плагіна.

Щоб повернути цей .svndir назад, з каталогу, що містить перешкоджений dir. Я роблю касу з --force. Наприклад, якщо plugin_dirпозначено "~", з його батьківського каталогу я запускаю:

svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir

Будь-які файли, які вже є там, залишаються в спокої і позначаються "E" на виході команди оформлення замовлення (позначається як "M" під час запуску svn status).

Мені іноді доводиться повертатися назад і додавати будь-які файли, які були новими з оновленням; або видалити файли, які слід видалити як частину оновлення, оскільки вони з'явилися знову, коли я зробив замовлення. Я вважаю, що вони позначені як "А" на касі, але наступні svn statusїх не згадують.

Я наткнувся на це в Eclipse, де деякі файли були позначені червоним знаком оклику. Проблемою була бродяча папка .svn у вихідному каталозі. Я видалив папку .svn, оновив затемнення і зміг перевірити файли.

Це також може статися під час оновлення підривної версії до версії, яку XCode не підтримує.

Ось найпростіший (і найбезпечніший) спосіб я вирішив це:

1. Тимчасово перейменуйте порушений файл або каталог (або батьківський каталог), який перешкоджає (наприклад, додайте ".backup").
2. Видаліть усі .svnкаталоги всередині перейменованого каталогу (якщо це застосовується).
3. svn revert перейменований (і зараз відсутній) об'єкт із кроку 1.
4. svn delete повернутий об'єкт.
5. Перейменуйте резервну копію від кроку 1 назад до її початкової назви.
6. Додайте і перевірте перейменований об’єкт назад у svn як новий об’єкт.

Це трапилось у мене, коли я замінив файл на папку, що має точно таке ім’я. Вирішується, видаливши старий файл, скопіюйте та додайте новий. Трохи хакі, але працював для мене :)

Я видалив .svn з перешкоджених каталогів та оновив його зовні. Тоді поза SVN команда розпізнає ці файли.