У меня есть РЕШЕНИЕ, используя класс предпочтений.
package com.example.android;
import android.content.Context;
import android.preference.Preference;
import android.util.AttributeSet;
public class VersionPreference extends Preference {
public VersionPreference(Context context, AttributeSet attrs) {
super(context, attrs);
String versionName;
final PackageManager packageManager = context.getPackageManager();
if (packageManager != null) {
try {
PackageInfo packageInfo = packageManager.getPackageInfo(context.getPackageName(), 0);
versionName = packageInfo.versionName;
} catch (PackageManager.NameNotFoundException e) {
versionName = null;
}
setSummary(versionName);
}
}
}
Я использую http://winmerge.org/
Я не думаю, что вы можете сделать то, что просите, из-за того, как алгоритмы самой длинной общей подпоследовательности работают для этих инструменты.
Даже если ваши функции будут перестроены, а функциональность исходного файла останется прежней, это все равно будет отображаться как разница из-за природы LCS.
РЕДАКТИРОВАТЬ:
Это немного надумано, но если вы чувствуете себя слишком амбициозно, вы могли бы написать свой собственный, который адаптирован к вашим конкретным потребностям.
вы можете использовать регулярные выражения для извлечения каждого метода в исходном файле и выполнять сравнение LCS для каждого метода индивидуально по своему названию. Вы можете сохранить свой код в словаре (ключ, значение), чтобы ключ был именем метода, а значение - строкой функции. Затем вы просто сравниваете свой dictionary_orig ['method'
Как многие предполагали, я полагаю, что такое сравнение будет невозможно с доступными инструментами сравнения. Потому что их цель - сказать, изменилось ли что-то, и если вы переместите метод от начала к концу, действительно что-то изменилось.
Но сейчас мне приходит в голову то, что вы можете сделать это самостоятельно. Обычно вызывается какой-то инструмент diff, который затем возвращает вновь вставленные строки, в основном метод, который вы переместили в конец вашего файла. Затем вы можете сами сравнить, присутствуют ли уже измененные строки в вашем предыдущем файле.
Я знаю, что вы ищете инструмент. Но так как я ничего не знаю, вот как я бы это сделал:
DiffMerge от SourceGear превосходен и доступен бесплатно.
Я использую KDiff и считаю, что он работает довольно хорошо. И, конечно же, бесплатно.
Не могли бы вы провести сравнение скомпилированных сборок? В таком случае .NET Reflector имеет доступную надстройку под названием Diff , которая позволит вам сравнить 2 сборки. Это определенно не заботит, где / как ваши объекты расположены внутри исходного файла.
Меня тоже это интересовало. Я не думаю, что он существует. Существуют «функциональные» (в отличие от просто текстовых) инструментов сравнения, доступные для других сценариев. Например, Microsoft Word интегрирует свою собственную функцию сравнения / слияния (которая может быть написана сценарием, поэтому ее можно интегрировать, например, с TortoiseSVN), а также есть несколько инструментов, доступных для XML, которые интерпретируют файлы XML, а не просто рассматривают их как текст.
Я не уверен, что дополнительная ценность такого инструмента по сравнению с хорошим текстовым инструментом сравнения / слияния будет достаточно убедительной, чтобы заслужить его разработку. OTOH, это может быть просто недостающее звено, решающее «боль слияния», которую мы все чувствуем, когда сталкиваемся с трудной ситуацией слияния.
Трудность, конечно же, в том, что вы должны интерпретировать код так же, как это делает компилятор C #. Я думаю, что на данный момент наиболее подходящим инструментом является NDepend. Это сообщение в блоге объясняет некоторые из его возможностей в этом отношении.
Воспользуйтесь нашим инструментом Smart Differencer , который сравнивает абстрактные синтаксические деревья, и сообщает о различиях в терминах нетерминалов ("языковых конструкций") что AST представляют, и возможные действия редактирования (вставка, удаление, перемещение), а также обнаружение последовательного переименования.
В настоящее время он обрабатывает только Java и COBOL, но он основан на DMS, который имеет синтаксические анализаторы для широкого спектра языков, включая C #.
РЕДАКТИРОВАТЬ 9/8/2009: C # SmartDifferencer теперь доступен для бета-тестеров.
Инструмент уже обрабатывает последовательное переименование всего файла как семантически тривиально (при условии, что другие файлы ссылаются на переименованный символ соответственно), а также переименовывает в пределах области видимости. Мы планируем учесть семантически тривиальные изменения, такие как как перемещение объявления метода в классе для Java и C #.
РЕДАКТИРОВАТЬ Октябрь 2010: Доступны производственные версии. Пробные загрузки доступно на веб-сайте.
РЕДАКТИРОВАТЬ Май 2012 г. : Вы можете увидеть пример C # на этой странице.
Одна из вещей, которые он сейчас не делает, - это игнорировать семантически нулевые изменения. Конкретный случай - это перемешивание методов в теле класса; все мы знаем, что это не влияет на семантику C #. Наш инструмент сравнивает синтаксис (через AST), а не семантику, поэтому он не понимает этот конкретный нюанс и, следовательно, вместо молчания сообщает пользователю, что «это было перемещено». У нас есть планы обрабатывать подобные случаи когда-нибудь в будущем, но, эй, у каждого продукта должна быть версия 1: -} [В качестве тонкого момента, методы перетасовки в классе Java также семантически равны нулю, но перетасовка полей не связано с порядком оценки инициализаторов. Я не
Beyond Compare от Scooter Software отлично подходит для этого, и это тоже дешево (30 долларов).