Pracuję w zespole, który opracowuje oprogramowanie Android. Niektórzy członkowie zespołu korzystają z systemu Windows, niektórzy korzystają z komputerów Mac i jestem znany z używania Linuksa. Wszyscy używają Eclipse.Eclipse project.properties ścieżki backslash za szkodliwe
Eclipse zapisuje plik o nazwie project.properties; oto przykład. Ważną częścią są ostatnie trzy linie, ścieżki odniesienia biblioteki Androida.
# This file is automatically generated by Android Tools.
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
#
# This file must be checked in Version Control Systems.
#
# To customize properties used by the Ant build system edit
# "ant.properties", and override values to adapt the script to your
# project structure.
#
# To enable ProGuard to shrink and obfuscate your code, uncomment this (available properties: sdk.dir, user.home):
#proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt
# Project target.
target=android-17
android.library.reference.1=../private-code/lib/SomeLibrary
android.library.reference.2=../google-play-services_lib
android.library.reference.3=../FacebookSDK
Powyższy opis wygląda tak, jak plik Eclipse na Maca lub Linux go pisze. Kiedy Eclipse w systemie Windows go zapisuje, linie odniesienia biblioteki są zapisywane z odwrotnymi ukośnikami.
Oczywiście w systemie Windows tylne ukośniki to dopuszczalne separatory ścieżek. Ale na systemach Mac i Linux takie ścieżki nie działają. Chodzi o to, że w systemie Windows ukośniki działają doskonale. Tak więc teraz naszą zasadą jest zawsze zatwierdzać plik z ukośnikami, aby działał on dla wszystkich.
Ale to jest uciążliwe dla naszych użytkowników systemu Windows, a dla reszty z nas jest to uciążliwe, gdy użytkownicy systemu Windows popełniają błąd, więc szukam rozwiązania technicznego. Mam dwa pomysły:
znaleźć ustawienie gdzieś w Eclipse na Windows, informując go użyć ukośniki podczas zapisywania ścieżki w plikach jak
project.properties. (Dlaczego do cholery nie jest to domyślne?!?)Używamy Mercurial, więc: zainstaluj jakieś "haczyki", które rozwiążą problem.
- Zainstalować zatwierdzenie zatwierdzenia na komputerach z systemem Windows, aby plik został zatwierdzony w repozytorium, a ukośniki odwrotne zastąpione są ukośnikami.
- Zainstalować zaczep na komputerze Mac i Linux; więc jeśli plik zostanie zatwierdzony z odwróconymi ukośnikami, zostaną one poprawione do czasu zapisania plików.
Hak popełnić wydaje czystsze, więc jeśli oba są dostępne zabrałbym commit hak na haku przeciwsobnym.
Znalazłem Mercurial rozszerzenie, które edytuje tabulatory do spacji, co jest przynajmniej w pewnym stopniu podobne do tego, co chcę. Jest na tyle złożony, że jestem trochę nieufny, próbując go zmodyfikować w to, czego potrzebuję.
https://www.mercurial-scm.org/wiki/CheckFilesExtension
Druga strategia jest dodanie hak, który wykrywa odwrotne ukośniki w ścieżkach i po prostu przerywa commit, zmuszając użytkownika systemu Windows, aby naprawić plik ręcznie przed popełnieniem. To byłoby lepsze niż nic.
Wobec tego problemu. Które rozwiązanie zadowoliło twój zespół? –
Jeszcze go nie rozwiązałem. Doszedłem do wniosku, że najlepsze rozwiązanie jest proste: haki, które powodują niepowodzenie, jeśli odwrócone ukośniki są niewłaściwe, a użytkownicy systemu Windows będą musieli to naprawić ręcznie. W tej chwili nikt nie robi podstawowych zmian w tym pliku, więc ten problem nie gryzie nas, a my wszyscy byliśmy zajęci i nie myśleli o tym. – steveha