Чи існує система контролю версій, яка може показувати зміни певного методу чи функції? [зачинено]


11

Іноді було б добре сказати:

(git|svn|hg|etc) diff Foo.c:main
(git|svn|hg|etc) log log Foo.c:main

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

  1. Чи існує щось, що робить це?
  2. Чи буде такий інструмент практичним? Потрібно було б виконати простий аналіз коду при кожному перегляді, щоб порівняти різні версії функції; хіба накладні витрати будуть занадто великими, щоб він був ефективним?

7
Потреба в цьому здається, що це буде симптомом основної проблеми, наприклад, як занадто великі методи або класи не організовані належним чином, оскільки будь-який VCS, який варто його солі, дасть вам відмінності класу, і досить просто прокрутити вниз шукати (або шукати) відповідний метод, якщо клас не надто великий, і ви побачите код методу в контексті всього класу. Словом, я вважаю, що роздільна здатність методу є надто специфічною.
Роберт Харві

@ Роберт, це хороший момент, і я думаю, що моя мотивація до роздумів частково обумовлена ​​хоча б невеликим роздумом коду. Я простежив помилку до конкретного методу і хочу, щоб я міг бачити журнал змін саме до цього методу, щоб побачити, де він зламався, і повна розріз може бути злегка незручною для пошуку, якщо ви поспішаєте :)
jches

4
У дуже рідкісному випадку, коли це корисно, функція вини TortoiseXXX є досить потужною. Ви можете бачити, коли останні зміни були внесені до всіх рядків методу, і, використовуючи правильний запас, продовжуйте крокувати назад через ці зміни.
пдр

Відповіді:


14
  1. Наскільки я знаю, це не так. Можна, але я б не очікував, що це буде якість виробництва, якби це було.
  2. Я не думаю, що це практично, але не з тієї причини, яку ви вказали. Це не практично, тому що VCS повинен мати знання мови, щоб підтримувати такі функції. По суті, вам потрібно буде вставити щось для розбору мовного тексту (один із великих кроків, який робить компілятор). Це додає вам багато зайвої ваги VCS, що вже виконує досить складну роботу.
    Але що ще важливіше, вам потрібно було б зробити те ж саме для кожної мови, яку ви хочете підтримати. Компанія VCS, яка продає лише робочий код C, не отримає великої тяги. Навіть якщо ви ігноруєте всі незрозумілі мови, було б великим завданням підтримувати навіть 10 кращих мов.

І як зазначав Роберт, можливість негайно перейти до методу - це не величезна вигода від необхідності перейти вручну до методу в інструменті diff.


4
Я другий з точки зору мовної залежності і маючи багато зайвого коду
Чандер Шивдасані,

1
Цей же аргумент можна зробити і проти редакторів підкреслення коду; вони повинні бути мовними та дійсно існувати. Можливо, окупність трохи більша (барвисті екрани кодексу!). Я погоджуюсь, що синтаксичний аналіз, можливо, буде найважчою. Підтримувати найпоширеніші мови не може бути важко, тим більше, що вам не потрібно повністю розбирати програму.
jches

8

svn насправді робить щось близьке до того, що ти хочеш.

Ви можете використовувати команду:

svn diff -x -p program.c 

-x -p Забезпечує ім'я функції «C» на верхній частині набору змін. що виглядає приблизно так.

@@ -97,6 +102,8 @@ int function1(int *x)

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

Я думаю, це лише для "C" (або C / C ++). Однак, я думаю, якщо є попит svn, він зробить його доступним і для інших мов.

Я не зовсім підписуюся на аргумент, що VCS НЕ повинен цього робити. Зрештою, ми хочемо, щоб усі IDE чи редактори (наприклад, VIM, EMACS) робили підсвічування синтаксису, яка є специфічною для кожної мови та підтримує багатьох одночасно. Отже VCS, будучи інструментом для розробників, також повинен підтримувати таку функціональність.

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


1

Не вдаючись до специфіки, ... але ви можете ознайомитись із сайтом Semantic Designs та їх асортиментом. Вони пропонують деякі засоби, які чутливі до мови , так би мовити, за відсутності кращого терміна.



-1

Щоб показати, яка редакція та автор востаннє змінили кожен рядок файлу:

git blame filename

1
Щоправда, але Q запитує спосіб пошуку змін певного методу у файлі. Уявіть, що в даному файлі є 100 змін, і серед тих, що вам потрібно знайти ті, що включають зміни певної функції.
Калеб

Контроль версій не знає деталей синтаксису, а також не хвилює типи файлів.
Ghita

-1

ENVY і StORE обидва роблять це. Цікаво, що, як і Монічелло, про якого згадував Логан Капальдо, вони теж є для Smalltalk.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.