Założeniem które przyświecało od początku jego istnienia była kompaktowość (wszystko w jednym pliku), używalność, wygoda. Wydaje mi się że jak na razie spełnia wszystkie wymienione ;) Ograniczeniami są PHP >= 4.3.0 i nie zablokowane wykonywanie funkcji proc_open () i proc_close ().

Zalety (z mojego punku widzenia ;) ):

• wszystko w jednym pliku (biblioteki jQuery pobierane są bezpośrednio z serwera jQuery.com
• obsługa aliasów
• prostota użytkowania
• historia poleceń

Wady:

• no cóż, to jednak nie prawdziwy shell…
• brak uzupełniania
• uprzyjemniacze typu historia wymagają połączenia z netem lub modyfikacji skryptu i używania lokalnych kopii bibioteki jQuery

Znane błędy:

• nie zapamiętuje ustawionego rozmiaru czcionki w okienku wyjścia
• czasem z jakiegoś powodu historia nie działa, trzeba np. otworzyć okienko konsoli w ff i je zamknąć, wtedy jest ok :/

Nie sprawdzałem też (ani nawet nie zamierzam jak na razie) sprawdzać jak wygląda i działa pod IE. Może się coś sypać :)

Jeśli ktoś jest zainteresowany tą zabawką, to zapraszam do pobierania na GoogleCode, i komentowania/krytykowania pod tą notką ;)

Do pobrania z GoogleCode. Jak zawsze proszę o informacje i uwagi nt działania wtyczki, a także ucieszyłbym się z informacji że ktoś gdzieś moich wypocin używa :)

Skrypt jak ciągle dostępny do pobrania z adresu: urzenia.net/wp-content/sblam_blacklist_update.txt.

Podziękowania dla Elusia za zwrócenie uwagi :)

• możliwość formatowania daty dodania statusu (via komentarz Julka)
• naprawione linkowanie tagów i userów - teraz łapie poprawnie polskie znaczki. Może nie do końca poprawnie działać jeśli kodowanie znaków jest inne niż UTF-8, proszę wtedy dać znać, mam wrażenie że coś źle przemyślałem ;)

Standardowo proszę o komentarze pod tym wpisem, lub na email :) A nowa wersja pluginu jest do pobrania na Google Code.

UPDATE:

Już nowa wersja - 0.3.1 ;)

• fix: pliterki w tagach teraz działają lepiej
• fix: myślnik w tagach też działa lepiej
• add: linki we wpisach są obejmowana tagiem <a />

Do pobrania tradycyjnie na GoogleCode.

• update BlipApi.php do nowej wersji
• linkowanie tagów i użytkowników
• dodanie pliku README z podstawową dokumentacją

Zainteresowanych zapraszam ściągania i aktualizowania :)

Nową wersję można pobrać ze specjalnie utworzonego w tym celu projektu na Google Code: blipapi.googlecode.com (jeśli ktoś kojarzy projekt blipapi-php na Google Code, to niech wymaże go ze swoich bookmarków, został usunięty).

Czego nie ma, a być powinno

Co mi się nie podoba: w “odrzuconych” są takie kwiatki jak add named parameters, czyli parametry nazwane w funkcjach. Jestem dość mocno skażony Pythonem, więc ten wynalazek uważam za świetny pomysł, niestety został odrzucony :(

O ile parametry nazwane to kwestia gustu, i da się to przeżyć, o tyle gorzej że ten sam los spotkał wpis oznaczony jako all fatal errors to become exceptions Chodzi tutaj o zamianę chorego systemu błędów (które potrafią ot tak zatrzymać działanie skryptu i nie pozwalające zrobić z tym faktem niczego) na wyjątki. Dziwna sprawa jak dla mnie, jako że ogólnie PHP5 już ma na tyle zaawansowaną obsługę wyjątków i obiektów w ogólności, że nie powinien to być problem. Tym bardziej, że to ma być zupełnie nowa wersja interpretera (nie podwersja), więc taka zmiana powinna być w pełni akcpetowalna :(

make function names match CS and unify parameter order - o ile zmiana akurat na camel case mnie nie bawi, bo wolę wersję z podkreśleniami, o tyle lepsze to niż obecna ruletka. A już druga część podpunktu (czyli unifikacja kolejności parametrów w funkcjach wbudowanych) to jak dla mnie takie “musiszmieć”, a oni to tak po prostu odrzucają. Porażka :( Co za problem, skoro i tak jest śmietnik, zostawić stare funkcje jako aliasy na nowe, dorzucając errora typu deprecated, i zrobić wreszcie jakiś porządek? :/

add support for <?php="foo" ?> - cóż, szkoda. Pozostanie pisać mi dalej w WordPressie <?php echo "foo"; ?> :) Ale nadmiernie z tego powodu nie rozpaczam :)

Nieco bardziej ruszył mnie punkt dotyczący wielokrotnego dziedziczenia, ale płakał też nie będę. Cóż, tak samo jak z punktem poprzednim, da się żyć bez tego.

Natomiast zupełnie nie rozumiem dlaczego odrzucono pomysł bloku finally (a ‘finally’ block for exception handling, bez którego system wyjątków jest, teges, upośledzony :(

O czym nie chciało im się jeszcze rozmawiać

Jednym z ciekawszych elementów nad którym nie przeprowadzono jeszcze dyskusji, jest dostarczenie globalnej funkcji __call (), wywoływanej w momencie gdy zostanie użyta nieistniejąca funkcja. Coś, czym jest __autoload () dla klas. Fajna sprawa, imho jak najbardziej powinno mieć to miejsce.

Ciekawostką jak dla mnie jest używanie wyrażeń regularnych w bloku switch (). Jeśli przepchną coś takiego, to pójdą w stronę perla, gdzie w wersji 5.10 dodano tenże blok (nazywając go given ()), który wykorzystuje magiczny, specjalnie dla niego stworzony operator ~~. Magiczny dlatego, że sposób jego działania (porównywania) jest zależny od tego jakie operandy są porównywane. Bez specjalnej tabeli (szukaj podpunktu Smart matching in detail) nie podchodź.

Za to dwa inne podpunkty mi się nawet podobają: “ext/pimpmydate”, new date/time features, real OO interface (obiektowe podejście do operowania na datach) i being able to use array() when defining constants (możliwość definiowania stałych jako tablice). Byłoby miło gdyby to zostało wprowadzone :)

Nad czym pracują i co na pewno będzie wykonane

Standardowo - pełne wsparcie dla Unicode. W końcu. Co prawda, podobnie jak porneL nie rozumiem czemu wybór padł akurat na UTF-16, ale lepsze to niż obecne zabawy z niepełnym modułem mb. Trwają jeszcze prace nad pełną implenetacją tego (np. w PDO), ale ważne że będzie ;)

Nie ma już register_globals i safe_mode. Te dwa zabytki, do spółki z magic_quotes są baaaardzo wkurzającymi, i często niebezpiecznymi ustawieniami dotyczącymi PHP. Na szczęście zmiany z tego podpunktu dotyczą także PHP 5.3. Hip hip, hurra! :D

Zostanie wyrzucone z głównego drzewa rozszerzenie ereg, za to pcre zostanie jego stałą częścią bez możliwości wyłączenia.

Do PHP wprowadzono goto. Na razie działa breakowanie do konkretnej etykiety (label), a niedługo dojdzie też goto jako takie… O ile break rozumiem, o tyle goto niespecjalnie.

Podoba mi się wprowadzenie rozwijania tablic do foreach. Wykorzystywałoby się w tym celu funkcję list (), a całość wyglądałaby tak:

$a = array (
  array (1, 2),
  array (3,4)
);
foreach ($a as $k => list ($b, $c)) {
  echo $b .':'. $c;
}

Przestrzenie nazw.

Wbudowane zabezpieczenie przeciwko HTTP Response Splitting (funkcją header () będzie można wysłać tylko jeden nagłówek naraz, czyli wstrzyknięcie “Header1: Value\nHeader2:Value” nie będzie już możliwe).

I co z tego?

Jako podsumowanie napiszę tylko, że wprowadzane zmiany są tak jakby… chaotyczne. Z jednej strony próba wyprowadzenia różnych zaszłości, które strasznie denerwują ludzi nieco bardziej obeznanych z programowaniem. Z drugiej zostawianie rzeczy i śmietnika które denerwują nie mniej. Teoretycznie, wersja piąta jest na tyle dobrą wersją tego języka, że dałoby się z nią przeżyć jeden rok więcej. Dzięki temu można by wprowadzić znacznie więcej zmian które oczyściłyby ten jeden wielki śmietnik, jakim jest PHP.

Do niedawna używałem prostego Pythonowego skryptu, który wywoływem z Vima:

!$ %

Wykrzyknik to polecenie wywołania programu z shella, $ to nazwa skryptu, a % jest rozwijany przez Vima do pełnej ścieżki bieżącego pliku. Było to o tyle wygodne, że nieważne w jakim języku pisałny był skrypt/program, $ uruchamiał odpowiedni interpreter, ze skonfigurowanymi parametrami i wyświetlał wyjście. Tą funkcjonalność oczywiście potrzebowałem zachować, ale wykonywanie zewnętrznego programu jest strasznie niewygodne ;) Więc zrobiłem sobie wygodniejszą, i nieco bardziej rozbudowaną wersję. Inne założenia to możliwość przekazywania parametrów do wykonywanego programu, oraz dla niektórych języków możliwość wcześniejszej, automatycznej kompilacji.

Założyłem taki format konfiguracji poszczególnych typów plików:

[wywolanie interpretera, przeksztalcenie pliku wykonywalnego]

Gdzie wywolanie interpretera może być tuplą/listą wywołań lub zwykłym napisem z kluczami:

fname

nazwa biezacego pliku

exe

nazwa wersji wykonywalnej (nie jest wymagane)

params

dodatkowe parametry

Klucze te są zastępowane oczywiście właściwymi danymi z wykorzystaniem skłądni “procentowej”. Przykład takiej konfiguracji:

'java':     [('javac -Xlint %(fname)s', 'java %(exe)s %(params)s'), lambda f: os.path.splitext (os.path.basename (f))[0], ],

W takim przypadku zostanie najpierw zostanie uruchomione polecenie javac -Xlint %(fname)s, następnie java %(exe)s %(params)s, gdzie %(fname)s zostanie zastąpione pełną ścieżką do bieżącego pliku, %(exe)s rezultatem działania funkcji lambda f: os.path.splitext (os.path.basename (f))[0] (która zwróci samą nazwę pliku bez ścieżki i rozszerzenia), a %(params)s - dodatkowymi opcjami. Zamiast funkcji generującej wersję exe można podać napis którym ma zostać zastąpione rozszerzenie pliku, lub None jeśli nie ma być w ogóle zmieniane.

Największym problemem było wygodne uruchamianie zbudowanej funkcji - lepiej mi używać już zewnętrznego skryptu niż pisanie na przykład:

python MDP_Execute ('arg1', 'arg2', 'arg3')

W tym celu stworzyłem sobie funkcję Vimową (nie pythonową!) o tej samej nazwie (czyli MDP_Execute ()), a do tego dorzuciłem komendę którą nazwałem Exe. Domyślnie komendy w Vimie nie pozwalają na używanie dodatkowych argumentów. Można jednak zmienić to zachowanie poprzez dodatkowy parametr -nargs, który może przyjąć wartości:

0

wartość domyślna, nie pozwalająca na argumenty

1

musi być dokładnie jeden argument (może to być oczywiście inna cyfra/liczba)

*

dowolna ilość argumentów

?

0 lub 1 argument

+

1 lub więcej argumentów

W moim przypadku odpowiednim parametrem była gwiazdka:

-nargs=*

Problemem jeszcze było odebranie tych parametrów wewnątrz funkcji, a także przekazanie ich do funkcji pythonowej. Rozwiązaniem była najpierw definicja funkcji Vimowej z “trzykropkiem”:

function! MDP_Execute (...)

dzięki czemu funkcja może przyjąć dowolną ilość argumentów (ale mniejszą lub równą 20 - ograniczenie Vima), a odbiera się je wewnątrz funkcji jako zmienne funkcyjne (tzn. takie które istnieją tylko wewnątrz funkcji) o nazwie takiej samej jak index tej funkcji. Jest to mało jasne wyjaśnienie, więc może przykład:

function! MDP_Execute (...)
    echo a:1 " wydrukuje pierwszy z parametrów wywołania
    echo a:2 " wydrukuje drugi z parametrów, etc
endfunction

Specjalne znaczenie mają dwie zmienne: a:0 i a:000 - pierwszy zawiera liczbę podanych (nienazwanych) parametrów, drugi zawiera listę tychże (wygodne gdy musimy po tym przeiterować).

Następnie trzeba było przekazać argumenty podane do komendy do funkcji. Robi się to za pomocą argumentu <args>, a konkretnie jego odmiany <q-args>, który automatycznie przekształca parametry komendy na odpowiednio sformatowaną wersję (czyli nie musimy sami wkładać poszczególnych parametrów w cudzysłowia jakby trzeba to było robic z wersją <args>). W tym momencie można już w funkcji Vimowej MDP_Execute () odebrać wywołanie komendy:

Exe arg1 arg2 "long arg3"

Pozostaje przekazanie tych samych argumentów do funkcji Pythonowej, ale tutaj po części wyręcza nas sam Vim - po prostu z wewnątrz funkcji pobierzemy sobie wartość zmiennej a:000 za pomocą wbudowanej w moduł vim funkcji eval ():

data['params'] = ' '.join (vim.eval ('a:000'))

Całość skrypciku wygląda tak:

if !has('python')
    echo "Error: Required vim compiled with +python"
    finish
endif

python << EOF
import os.path
import subprocess
import types

import vim

def MDP_System (cmd):
    p   = subprocess.Popen (cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)
    ret = list (p.communicate ())
    ret.insert (0, p.returncode)
    return ret

def MDP_GetFileType (default=None):
    ft = vim.eval ('&ft')
    if not ft:
        ft = os.path.splitext (vim.current.buffer.name)
        if len (ft) > 1:
            ft = ft[1][1:].lower ()
        else:
            ft = default

    return ft

MDP_Run_Script_ftypes = {
    'python':   ['python -tt %(fname)s %(params)s', ],
    'perl':     ['perl %(fname)s %(params)s', ],
    'sh':       ['bash %(fname)s %(params)s', ],
    'txt':      ['bash %(fname)s %(params)s', ],
    'php':      ['php -f %(fname)s %(params)s', ],
    'cs':       [('mcs %(fname)s', 'mono %(exe)s %(params)s'), '.exe', ],
    'd':        [('rebuild -oqobj %(fname)s', '%(exe)s %(params)s'), '', ],
    'java':     [('javac -Xlint %(fname)s', 'java %(exe)s %(params)s'), lambda f: os.path.splitext (os.path.basename (f))[0], ],
}

def MDP_Execute ():
    cmd_data = MDP_Run_Script_ftypes.get (MDP_GetFileType (), '')
    if not cmd_data:
        print 'Unknown filetype to execute'
        return

    if not isinstance (cmd_data[0], (list, tuple)):
        cmd_data[0] = ( cmd_data[0], )

    data = dict (
        fname   = vim.current.buffer.name,
        params  = ' '.join (vim.eval ('a:000')),
        exe     = vim.current.buffer.name,
    )

    # jesli trzeba, to wyszukujemy wersje exe
    if len (cmd_data) >= 2:
        if isinstance (cmd_data[1], str):
            tmp = os.path.splitext (data['fname'])[0]
            if cmd_data[1]:
                tmp += '.' + cmd_data[1]
            data['exe'] = tmp
        elif isinstance (cmd_data[1], types.FunctionType):
            data['exe'] = cmd_data[1] (data['fname'])

    for c in cmd_data[0]:
        res = MDP_System (c % data)
        print res[1]
        if res[0]:
            print 'Błąd:'
            print res[2]

EOF
function! MDP_Execute (...)
    python MDP_Execute ()
endfunction
command! -nargs=* Exe call MDP_Execute (<q-args>)
map <C-e> <Esc>:call MDP_Execute ()<cr>

Ostatnia linijka odpowiada za wykonanie skryptu (bez żadnych parametrów) po wciśnięciu kombinacji klawiszy Ctrl+e. Jeśli wymagane są jakiekolwiek parametry, trzeba ręcznie wywołać komendę Exe podając po niej wymagane do poprawnego działania naszego programu argumenty :)

Przede wszystkim, model obiektowy Pythona jest zupełnie inny niż PHP. Nie będę go tu omawiał, ponieważ to temat na dość obszerną książkę :) Generalnie obiektówka Pythona jest pełniejsza, ma większe możliwości przeciążania zarówno metod, jak i operatorów (których w PHP przeciążyć nie można).

Podstawą do pisania własnych setterów i getterów są w Pythonie dwie metody magiczne: __getattr__() i __setattr__(). Istnieje także metoda __delattr__() służąca do implementacji usuwania konkretnego atrybutu. Dobra, koniec smęcenia, może jakiś przykład:

class Test (object):
  x = 1
  def __init__ (self):
    super (Test, self).__setattr__ ('data', dict ())
  def __setattr__ (self, var, value):
    self.data[var] = value
  def __getattr__ (self, var):
    return self.data[var]

Wtrącę jednak małe omówienie obiektówki Pythonowej: w Pythonie 2.x są dwa modele klas: nowy i stary. Deklaracja klasy nowego typu oznacza jawne dziedziczenie z obiektu object, co zobrazowane jest w linii pierwszej (zalecane jest korzystanie z nowego typu klas).

Inną ciekawostką jest deklarowanie właściwości obiektu (które są współdzielone między instancjami - zmiana jej wartości w jednej instancji powoduje też jej zmianę w drugiej instancji) i właściwości instancji (które są indywidualne dla każdej instancji): pierwsze deklaruje się w ciele klasy, co pokazane jest w linii drugiej. Drugie “dodaje się” w konstruktorze czy też dowolnej innej metodzie (z konwencji robi się to w konstruktorze, który w Pythonie nazywa się __init__ ()). W naszym przykładzie sytuacja się nieco komplikuje, jako że my nadpisujemy wbudowaną metodą __setattr__ (). Aby dodać sobie właściwość instancji, musimy skorzystać z metody __setattr__ () superklasy klasy Test (czyli object), co pokazuje nam linia czwarta. W linii tej deklarujemy sobie jakiś słownik (w PHP nazywa się tą strukturę tablicą asocjacyjną), w którym będziemy przechowywać nasze dane. Tutaj występuje pewna różnica w stosunku do PHP, gdzie metoda __set wykonywana jest w momencie gdy właściwość którą próbujemy ustawić nie jest zadeklarowana w obiekcie, lub gdy jest do niej ograniczony dostęp za pomocą akcesora private. W Pythonie metoda __setattr__ () używana jest przy dostępie do jakiejkolwiek właściwości (zadeklarowanej wcześniej lub też nie). Jeśli sam sobie w definicji __setattr__ () nie zapewnisz dostępu do jakiejś właściwości, to nie będziesz jej miał. Trzeba pamiętać przy tym, że sama metoda __setattr__ () nie korzysta z samej siebie, czyli wewnątrz niej mamy dostęp do zadeklarowanych wcześniej właściwości.

Wróćmy do przykładu. Nasz setter dodaje do słownika data (lub zmienia wartość) klucz var, przypisując mu wartośc value. Getter po prostu zwraca szukaną właściwość, lub też, jeśli nie została jeszcze zdefiniowana, rzuci wyjątkiem (przydałoby się przechwycenie go i rzucenie właściwego wyjątku, ale to już inna kwestia).

A co jeśli trzeba dorobić sprawdzanie poprawności niektórych własności? No cóż, trzeba to zrobić podobnie jak w PHP, czyli zadeklarować dla nich konkretne metody sprawdzające.

class Test2 (object):
  def __init__ (self):
    super (Test2, self).__setattr__ ('data', dict ())
  def __setattr__ (self, var, value):
    if hasattr (self, '_check__' + var):
      self.data[var] = getattr (self, '_check__' + var) (value):
    self.data[var] = value
  def __getattr__ (self, var):
    return self.data[var]
  def _check__X (self, value):
    if isinstance (value, int) or (isinstance (value, str) and value.isdigit ()):
      return int (value)
    raise ValueError (u'Podana wartość nie jest liczbą!')

Ten kod pozwoli na przypisanie dowolnej wartości wszystkim własnościwościom poza X, której jedyną możliwą wartością do przypisania jest integer, lub napis zawierający same cyfry. W przypadku podania innej wartości zostanie rzucony wyjątek ValueError.

Powyżej została opisana jedna z możliwości stosowania własnych setterów i getterów. W Pythonie 2.2 została dodana jeszcze jedna możliwość, ta bardziej lubiana przeze mnie: funkcja (którą od wersji Pythona 2.4 można użyć jako dekorator) property (). Funkcja ta bierze od jednego do czterech parametrów. Pierwszym z nich jest metoda pełniąca funkcję gettera, druga - settera, trzecia - funkcji usuwającej właściwość, a czwarta - napis dokumentujący. Jeden ze sposobów użycia:

class Test3 (object):
  def __init__ (self):
    self.data = dict ()
  def _set__X (self, value):
    if isinstance (value, int) or (isinstance (value, str) and value.isdigit ()):
      self.data['X'] = int (value)
      return
    raise ValueError (u'Niewłaściwa wartość')
  def _get__X (self):
    return self.data['X']
  X = property (_get__X, _set__X)

Powyższy przykład robi dokładnie to samo co wcześniejszy Test2, z wyjątkiem umieszczania wszystkich własności w słowniku data. Różnice widoczne sa tylko w implementacji, dla użytkownika klasy różnice nie występują.

Funkcja property pozwala także na stworzenie atrybutu tylko do odczytu:

class Test4 (object):
  def __init__ (self, x):
    self.__x = x
  @property
  def x (self):
    return self.__x
t = Test4 (5)
print t.x
t.x = 6

Wykonanie kodu z ostatniego przykładu spowoduje rzucenie wyjątku AttributeError.

Jedną z tych zmian jest wycofanie konstrukcji językowej, jaką był print. Został on zastąpiony funkcją o dość nietypowej, zaskakującej nazwie, jaką jest print() ;) Czym się różnią?

Konstrukcja print była zupełnie niekonfigurowalna. Zawsze łączył podane elementy znakiem spacji, prawie zawsze na końcu sam dodawał znak nowej linii… Jedyną sensowną metodą naprawy tego było ręczne pisanie do sys.stdout, co do ładnych rozwiązań nie należało. Funkcja print() rozwiązuje ten problem za pomocą parametrów nazwanych, do których należą m.in. sep i end. Pierwszy odpowiada za separator parametrów, a drugi za znak dodawany na końcu konstrukcji. Czyli jeśli mamy do wyświetlenia 3 elementy, które chcemy rozdzielić znakiem wykrzyknika, a zakończyć znakiem hasza, w Pythonie 2.x zrobilibyśmy np.:

print '!'.join ('a', 's', 'd')+'#',

lub:

print 'a' + '!' + 's' + '!' + 'd' + '#',

W Pythonie 3000 będzie to wyglądało nieco ładniej:

print ('a', 's', 'd', sep='!', end='#')

W Pythonie 2.x można było także skorzystać z alternatywnej składni, która pozwalała nam pisać do dowolnego ‘uchwytu’ (np. otworzonego pliku, ja często z tego korzystałem przy wypisywaniu błędów na STDERR):

print >>sys.stderr, "komunikat błędu"

W nowej wersji składnia tego typu jest niedostępna, zamiast tego jest inny parametr nazwany: file:

print ("komunikat błędu", file=sys.stderr)

Druga z rzeczy które chciałbym pokazać to formatowanie tekstu. Do tej pory można było korzystać ze składni “z procentem”:

print 'liczba całkowita: %d, liczba zmiennoprzecinkowa: %0.1f' % (3.14, 3.14)

Ta składnia w Pythonie 3000 nie będzie już obsługiwana, zamiast tego wszystkie obiekty typu string dostały nową metodę: .format(). Metoda ta umożliwia znacznie bardziej rozbudowane formatowanie i konwersję podawanych parametrów, niż do tej pory było to możliwe za pomocą składni “procentowej”. Dajmy na to taki przykład:

class mysz:
  def __init__ (self):
    self.fname = 'Marcin'
    self.lname = 'Sztolcman'
    self.nname = 'MySZ'
    self.age = 28
    self.city = 'Szczecin'
  def __str__ (self):
    return '{0.fname} {0.nname:_^10} {0.lname}'.format (self)

print ('Jestem {0}, mam {0.age} lat, i mieszkam w mieście {0.city}.'.format (mysz ()))

Przykład jest może nieco infantylny ;) ale pokazuje to co chciałem pokazać: zaawansowane możliwości formatowania tekstu, jakich użycza nam metoda .format(). Powyższy przykład powinien nam wyświetlić:

Jestem Marcin ___MySZ___ Sztolcman, mam 28 lat, i mieszkam w mieście Szczecin.

Pełna składnia i format napisów formatujących opisany jest w Pythonowym manualu: docs.python.org/dev/3.0/library/string.html#format-string-syntax. Ja powiem tylko że po tym jak troszę się tym pobawiłem, zrozumiałem powody rezygnacji z mojej naprawdę bardzo lubianej składni, jak ją nazwałem, “procentowej” na rzecz .format() :)

Oczywiście Python 3000 wprowadza znacznie więcej zmian i nowości, być może jeszcze kilka z nich opiszę niedługo na łamach tegoż bloga (obiecuję że się postaram ;) ).

Padła propozycja dołączenia systemu “Cech” (ang. Traits) do PHP (podejrzewam że do wersji 6, ale to tylko moje zgadywanie - w każdym bądź razie są gotowe łatki m.in. do 5.2 i 5.3). Do czego służą Traitsy? W sumie… do obejście problemu jednodziedziczenia, czyli do wprowadzenia wielodziedziczenia.

Trzeba pamiętać, że ten mechanizm został podobno (nie sprawdzałem osobiście) sportowany także do Javy i C#, natomiast nie istnieje jeszcze ofiacjalna wersja dla PHP. Sam “wygląd” kodu, słowa kluczowe etc nie są jeszcze ustalone, ale to tylko szczegóły.

Szczegóły są dostępne w oficjalnym RFC: stefan-marr.de/artikel/rfc-traits-for-php.html. Ja tylko powiem, że da się często obejść niedogodność wynikajacą z braku wielodziedziczenia, ale problem leży właśnie w konieczności obchodzenia braków w języku (tak, wiem, to akurat jedna z typowych wojen wyższości jednych świąt nad drugimi ;) ale to akurat moje zdanie ;) ). Prostszym wyjściem byłoby wprowadzenie po prostu możliwości posiadania kilku klas bazowych, ale w to nie wnikam. Ja ogólnie jestem na tak.

Domyślnie, TrueCrypt dla linuksa potrafi sformatować nowy wolumen tylko jako FAT32. Można to nieco obejść, samemu formatując wolumen, a w oknie wyboru typu systemu plików, wybrać None (cały proces tworzenia wolumenu wraz ze zrzutami obrazów na jarzebski.pl). Następnie trzeba zamontować stworzony wolumen, ale zaznaczając opcję w oknie dialogowym ‘Do not mount’. Teraz pozostaje sformatować urządzenie loopbackowe (w moim przypdku było to /dev/loop0 - można podejrzeć wynik polecenia mount) na wybrany system plików (ext3 w moim wypadku), odmontować, zamontować ponownie już bindując pod wybrany katalog, i zacząć używać tak stworzonego wolumenu.

Problemy także występują przy próbie użycia kluczy. Jeśli wybrałem dowolny klucz (klucze teraz działają nieco inaczej niż w poprzedniej wersji TrueCrypta - do wersji 4.3 były generowane przez sam program, w tej chwili wskazuje mu się dowolną ilość plików i te pliki są traktowane jako klucze) przy tworzeniu wolumenu, to nie dało się podmontować go - krzyczał że niewłaściwy klucz. Okazało się, że klucze zostały olane, i montować trzeba bez nich ;) Za to po dodaniu kluczy do już stworzonego wolumenu wszystko działa jak powinno.

Od długiego czasu używałem swojego skryptu do montowania zaszyfrowanych wolumenów TrueCrypta. Oczywiście, jako zatwardziały zwolennik konsoli, działa on w trybie tekstowym :) Mam stworzony mały pliczek mapujący konkretną nazwę (alias) na plik zaszyfrowanego wolumenu, klucz użyty do zaszyfrowania go, i katalog pod który należy podmontować wolumen. Tutaj wyszedł problem - po każdym wywołaniu truecrypta z wybranymi opcjami, otwierało mi się okienko GUIowe i kazało klikać :/ Tutaj pomogło dodanie parametru -t do wywołania TrueCrypta.

Pozostał jeszcze jeden kłopot. Teoretycznie, nie można pod linuksem stworzyć “ukrytego wolumenu” - na etapie tworzenia wyskakuje monit “The selected feature is currently not supported on your platform.”. Więc, niech mi ktoś wyjaśni, dlaczego po próbie zamontowania zaszyfrowanego pliku w trybie tekstowym, dostaję jeszcze pytanie o włączenie ochrony ukrytego wolumenu? :/ I nie da się tego wyłączyć (OK, ja nie znalazłem, jeśli komuś się udało to proszę o info).

No dobra, powyżej skłamałem. Obeszłem problem brzydkim hackiem - w swoim skrypcie po prostu pobieram hasło samodzielnie, a następnie przekazuję je do odpowiednio wywołanej instancji TrueCrypta poprzez STDIN. Brzydkie, brudne, i źle działa przy błędnie wpisanym haśle, ale to akurat szczegół. Ważne że chwilowo działa…

To by było na tyle moich bojów z nową wersją programu. Zainteresowanych tematem odsyłam do dwóch artykułów:

• wspomniany wcześniej artykuł na jarzebski.pl
• bardzo ciekawy artykuł na temat starszej wersji TrueCrypta na jakilinux.org

Postanowiłem więc napisać sobie prosty skrypt do tego, a że język wewnętrzny Vima mnie nieco odrzuca, postawiłem na Pythona ;) Żeby jakikolwiek skrypt pythona (jak ktoś lubi, można użyć też np perla) mógł zadziałać w Vimie, ten ostatni musi być skompilowany z jego obsługą. W Ubuntu wystarczy zainstalować pakiet vim-full. Łatwo sprawdzić czy Vim ma wkompilowaną obsługę pythona:

vim --version|gi '+python'

Jeśli wyświetliła Ci się podobna linijka:

+python +quickfix +reltime +rightleft +ruby +scrollbind +signs +smartindent

to znaczy że możesz śmiało używać pythona do oskryptowania Vima :)

Skrypty Pythona w Vimie przekazywane są do funkcji Vimowej o zaskakującej, nietypowej nazwie python. Tradycyjne Hello world wyglądałoby tak:

:python print "Hello world"

Interakcję z samym Vimem umożliwia nam moduł o kolejnej zaskakującej nazwie: vim, który powinniśmy zaimportować na początku funkcji/skryptu. Szczegółowa jego dokumentacja jest na stronach Vima: vim.org/htmldoc/if_pyth.html.

Pierwszym krokiem jest wczytanie zawartości całego bufora. Do jego zawartości dostajemy się poprzez obiekt vim.current.buffer:

fc = "\n".join (line for line in vim.current.buffer)

Samo wyszukanie deklaracji funkcji w plikach pythona można by zrobić mniej więcej tak:

re.findall (r'^\s*def\s+(\w+)', fc, re.M)

Jednak nam najwygodniej pobrać będzie jednocześnie z nazwą funkcji, także całą linijkę w której ta została zdefiniowana. Przyda to się przy przechodzeniu do miejsca w kodzie w którym funkcja jest zdefiniowana. Ja końcowo zrobiłem to tak:

re.findall (r'^(\s*def\s+(\w+\s*\(.*?\))\s*:)', fc, re.M)

Teraz, gdy mamy listę funkcji, trzeba je wyświetlić userowi, a następnie pobrać informację do deklaracji jakiej funkcji w kodzie chcemy się przenieść. Najpierw chciałem skorzystać ze standardowego pythonowego raw_input (), ale ta funkcja w Vimie nie działa. Użyłem wobec tego Vimowego input (). Aby skorzystać z funkcji Vimowych, moduł vim udostępnia nam dwie funkcje: vim.eval () i vim.command (). Tutaj odpowiedni będzie vim.eval ():

choice = vim.eval ('input ("Which one: ")')

W tej chwili mamy już praktycznie napisany cały skrypt. Pozostało tylko znalezienie offsetu w jakim się zaczyna deklaracja wybranej przez usera funkcji w buforze, a następnie za pomocą vim.command () przenieść kursor w wybrane miejsce:

vim.command ('goto '+str (pos+1))

Całość w moim wykonaniu jest nieco bardziej rozbudowana (minimalnie), jako że staram się zrobić sobie mały framework do skryptowania Vima. Wycinek realizujący odpowiednią funkcjonalnośc w moim przypadku wygląda tak:

" importy ogólne, przydatne funkcje, etc
python << EOF
import re
import sys

import vim

def MyDevPlugins_GetFileType (default=None):
	ft = vim.eval ('synIDattr(synID(line("."), col("."), 1), "name")')
	if ft:
		m = re.findall (r'^([a-z]+)', ft)
		if m:
			return m[0]
	if not ft:
		ft = default

	return ft

EOF

" FindSubs - wyszukiwanie funkcji
python << EOF
FindSubs_ftypes = {
	'perl':		r'^(\s*sub\s+(\w+(?:\s*\(.*?\))?))',
	'python':	r'^(\s*def\s+(\w+\s*\(.*?\))\s*:)',
	'php':		r'^(\s*function\s+(\w+\s*\(.*?\)))',
}
FindSubs_ftypes['java'] = FindSubs_ftypes['html'] = FindSubs_ftypes['php']

def FindSubs_Find (ft='perl'):
	try:
		rxp = FindSubs_ftypes[ft]
	except KeyError:
		print 'Unknown filetype: "%s"' % ft
		return

	# read buffer content
	fc = "\n".join (line for line in vim.current.buffer)

	# find all functions names
	m = re.findall (rxp, fc, re.M)
	if not m:
		print 'Not found'
		return

	# print them for user
	for i, sub in enumerate (m):
		print '%d. %s' % (i+1, sub[1])

	# ask for function he want to go
	choice = vim.eval ('input ("Which one: ")')
	try:
		choice = int (choice) - 1
	except:
		print 'Incorrect value'
		return

	# find file offset
	pos = fc.find (m[choice][0].strip ())
	if pos < 0:
		print >>sys.stderr, "Some error occured."
		return

	# and go there
	vim.command ('goto '+str (pos+1))

def FindSubs_Main ():
	FindSubs_Find (MyDevPlugins_GetFileType ())

EOF

function! FindSubs()
	python FindSubs_Main()
endfunction
map <F5> :call FindSubs ()<CR>

Ostatnia linijka odpowiada za podmapowanie wywołania funkcji pod klawisz F5.

Natomiast problemy sprawia opcja rozpoznawania typu pliku. Nie doszukałem się nigdzie w dokumentacji lepszego sposobu, a ten czasem zawodzi :( Nic na to chwilowo nie poradzę. Oczywiście przydałoby się rozpoznawanie większej ilości języków, ale to co jest obecnie wystarcza mi w zupełności, w razie czego można sobie dorobić odpowiednie regexpy do słownika FindSubs_ftypes.

perl -e 's^^i6(!@*^+s;\*; Wo\$_\;~;.s![(_\!]!l!g+y"i\$@"Hro"+tr-6;~-ed\012-;print'

Ja leżę i kwiczę :)

Źródło: goldenline.pl/forum/perl/127239

Jedną z rzeczy z tym związanych jest usunięcie mojego repo (repo.urzenia.net). Cała jego zawartość znajdzie się niedługo jako konkretne projekty na code.google.com. W sumie już wszystko przeniosłem, poza BlipApi.php, które też się tam niedługo znajdzie. Nowe adresy projektów to:

mPack

zestaw bibliotek pomocnych przy tworzeniu serwisów w PHP: m-pack.googlecode.com.

useless-scripts

kilka skryptów które wykorzystuje w mojej codziennej pracy na komputerze: useless-scripts.googlecode.com. Tutaj też dostał się mój ostatni “produkt” killer.pl.

WP Blip!

Plugin do WordPressa, wyświetlający na nim ostatnie wpisy z serwisu Blip!: wp-blip.googlecode.com.

Killer to skrypt w perlu który wyświetla tabelę dostępnych procesów, i pozwala wysłać dowolny sygnał (komenda kill w linuksie) do wybranych procesów. Działanie jest bardzo proste, wygląd jeszcze bardziej… Jak ktoś ma ochotę dorobić ładne cssy to jestem za tym żeby je tam dorzucić ;)

Skrypt jest do pobrania z jego strony domowej: repo.urzenia.net/Perl:Killer.

Jako ciekawostka: model jaki wybraliśmy jest w “Nie dla idiotów” tańszy niż w większości sklepów w necie… Zdziwiłem się - choć wyboru nie miałem, musiałem kupić go w MM ;)

Wybrałem dla niej Toshibę Satellite A200 1S9. IMHO bardzo fajny sprzęt za tą cenę, dobrego i lubianego przeze mnie producenta (zawsze lubiłem laptopy Satellite).

Wybierając go zrobiłem jeden błąd, którego wystrzegałem się całe moje informatyczne “rzycie”: w laptopie jest karta ATI. O ile nie jest to problem pod Windowsem, o tyle na tym laptopie Windows będzie używany raz na kilka miesięcy. W sumie zrobiłem także drugi błąd, ale jego się nie wystrzegałem wcześniej ;) Tym drugim błędem jest to że jest tam karta sieciowa (wszędzie poniżej mówię o Wi-Fi) do której nie znalazłem działających wolnych sterowników, a ndiswrapper średnio sobie z nim radzi…

OK, wymieniłem 2 najważniejsze problemy, a poniżej sposób na poradzenie sobie z nimi.

Moje założenia które przyświecały mi przy instalacji:

• Windows na laptopie zostaje (dysk jest 160GB więc te 20GB Ania przeżyje)
• instalowanie z płyty Ubuntu Gutsy (7.10)

Na pewno nie ma sensu próby wywalenie Windowsa i instalacja go z dostarczanej płyty na własnym rozmieszczeniu partycji - instalator na to nie pozwala :( Trzeba odpalić system z płyty Ubuntu (przy starcie komputera F12 i wybrać bootowanie z DVD), po uruchomieniu środowiska graficznego uruchomić GParted (System -> Administracja -> Partition Editor), i tam wybrać zmniejszenie drugiej partycji (pierwsza to jakaś backupowa czy inne gówna Toshibianego Windowsa, lepiej to zostawić w sumie). Z powstałego w ten sposób wolnego miejsca utworzyłem najpierw partycję Primary na swap (1024MB), z pozostałego miejsca parycję Extended, a na niej dwie partycje logiczne: 20480 na / (trzeba ustawić taki punkt montowania) z systemem plików ext3, a resztę podpiąłem pod /home (również ext3).

Przechodzimy dalej, aż do etapu gdy zacznie się wszystko kopiować na dysk. Niech sobie kopiuje, wróć do tekstu za jakąś godzinę…

Zakładam że wszystko jest już skopiowane, system się zrestartował i uruchomił na nowo i wszystko gra i buczy. Prawie wszystko…

Trzeba zacząć od instalacji sieci. W tym celu potrzebny jest najnowszy kernel dostępny w repo (2.6.22-14). Ściągamy go (korzystając z drugiego kompa lub logując się na Windowsie), wracamy do linuksa, i instalujemy:

% sudo dpkg -i linux*deb

Potrzebny będzie także pakiet ndiswrapper i madwifi - znajdziesz je na płycie instalacyjnej. Potraktować je należy podobnie jak te z kernelem. Teraz trzeba podrzucić Windowsowy sterownik do karty sieciowej ndiswrapperowi. W tym celu na konsoli przechodzimy do katalogu Windowsa (/media/sdb2/Windows/System32) i poleceniem:

sudo ndiswrapper -i net5211.inf

instalujemy sterownik. Upewniamy się że system nie załaduje nam sterowników ‘natywnych’:

sudo rmmod ath-pci ath-hal

Do /etc/modprobe.d/blacklist jako root dopisujemy:

blacklist ath-pci
blacklist ath-hal

Usuwamy i dodajemy ponownie moduł ndiswrapper:

sudo rmmod ndiswrapepr
sudo modprobe ndiswrapper

W tym momencie sieć powinna już działać. Jeśli po wydaniu komendy iwconfig znajdziesz interfejs wlan0, to wszystko OK. Jeśli nie, to poszukaj na wiki ndiswrappera co może nie być w porządku.

Jeśli chodzi o interfejs Wi-Fi, to pozostaje kazać zapisać konfigurację modułów:

sudo ndiswrapper -m
sudo ndiswrapper -mi
sudo ndiswrapper -ma

Pozostaje skonfigurować dostęp do sieci korzystając z NetworkManagera, i powinno działać.

Niestety, nie zawsze po restarcie sieć wstaje. Nie miałem czasu szukać czemu i czy można coś na to zaradzić. Najprostszą metodą jest zrestartowanie komputera (czasem kilkukrotne), można też spróbować usunąć i ponownie załadować moduł ndiswrapper:

sudo rmmod ndiswrapper
sudo modprobe ndiswrapper

Z kartą graficzną jest mniejszy nieco problem (jeśli już się wie czego szukać i co zrobić). Nie ma sensu instalowanie z repo sterowników ‘radeonhd’ czy ‘flgrx’ - nie działają (przynajmniej na chwilę obecną). Nie ma sensu też ściągać ze strony ATI najnowszej wersji sterów (również nie działają). Chyba za świeży chipset :(

Jedynym rozwiązaniem które zaczęło mi działać, to samemu skompilować moduł ‘radeonhd’ z repozytorium. Cała operacja jest opisana na stronie phoronix.com/scan.php?page=article&item=843&num=1.

To samo po polsku w kilku krokach:

1. Trzeba zainstalować na początek kilka narzędzi w systemie:

   sudo apt-get install build-essential git-core configure-debian automake autoconf xorg-dev libtool

2. pobieramy źródła modułu:

   git-clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-radeonhd

3. budujemy i instalujemy moduł:

   cd xf86-video-radeonhd/
   ./autogen.sh --prefix=/usr/
   make
   sudo make install

4. poprawiamy konfigurację serwera X, zmieniając obecny sterownik (prawdopodobnie vesa) na radeonhd. Edytujemy w tym celu plik /etc/X11/xorg.conf jako root, znajdujemy linijkę Driver "vesa" i zmieniamy co trzeba. Ddodatkowo trzeba na razie ręcznie wyłączyć kilka modułów, których ta wersja sterownika na razie nie pbsługuje. Na końcu tego pliku trzeba dopisać:

   Section "Extensions"
   Option "Composite" "Off"
   EndSection
   
   Section "ServerFlags"
   Option "AIGLX" "Off"
   EndSection

Voila! :)

Jakaś dokumentacja pojawi się niedługo na stronie projektu (repo.urzenia.net/PHP:WP_Blip!wp-blip.googlecode.com), w tej chwili sam plugin można pobrać ze strony na Google Code (code.google.com/p/wp-blip).

Krótka instrukcja obsługi:

• pobrać plik z Google Code, rozpakować go w katalogu
  WORDPRESS_ROOT/wp-content/plugins (zostanie utworzony katalog
  wp-blip)
• w panelu administracyjnym Wordpressa uaktywnić plugin
• w Options->WP Blip! ustawić login i hasło do swojego konta w Blip!ie (także kilka innych opcji)
• gdzieś w szablonie dodać wywołanie funkcji:

  <?php
  if (function_exists ('wp_blip')) { wp_blip("\n", 1); }
  ?>

Wszelkie uwagi mile widziane :) Można je zostawić w komentarzach do tego wpisu, lub dowolną inną metodą (kilka metod kontaktu ze mną opisanych jest na podstronie urzenia.net/kontakt).

]]> http://urzenia.net/353/wp-blip-v01/feed/ http://urzenia.net/353/wp-blip-v01/ http://feeds.feedburner.com/~r/mysz/~3/205067731/ http://urzenia.net/351/sposob-pracy-na-subversion-branche-tagi-etc/#comments Sun, 23 Dec 2007 11:00:50 +0000 MySZ http://urzenia.net/351/sposob-pracy-na-subversion-branche-tagi-etc/ Musiałem utworzyć do firmy mały poradnik, jak korzystać z branchy i tagów w Subversion, a że pisałem to w miarę (jak mi się zdaje) łopatologicznie, to stwierdziłem że umieszczę to i tutaj dla szerszego grona :)

Nie jest to pozycja dla osoby nie mającej dotychczas styczności z Subversion, nie jest więc wytłumaczone co to jest commit i w ogóle Subversion czy też system kontroli wersji, są za to informacje jak ja i kilka osób na świecie widzą korzystanie z tak ważnych rzeczy jakimi są branche i tagi :)

Generalnie, podstawową strukturą katalogów jest układ:

/
|-trunk
|-branches
|-tags

W trunk przechowywana jest aktualna rozwojowa wersja systemu. Tutaj nanoszone są bieżące zmiany, poprawki etc. Branches służą do przechowywania oddzielnych gałęzi systemu, które niosą zbyt rewolucyjne zmiany, żeby umieszczać je w drzewku głównym, które musi być czasem gotowe do natychmiastowej synchronizacji z systemem głównym. W katalogu tags tworzone są aktualne snapshoty systemu produkcyjnego - każda wersja, która idzie na system produkcyjny, powinna najpierw zostać przeniesiona (zamrożona) do konkretnego taga, i dopiero później system powinien zostać zsynchronizowany.

Najpierw troszkę samej teorii:

Zarówno branche, jak i tagi, tworzone są poprzez skopiowanie dowolnej z gałęzi
rozwijanego systemu (może to być zarówno system trunk, jak i dowolna gałąź utworzona przez któregokolwiek użytkownika) poleceniem cp (copy):

svn cp svn://repo/trunk svn://repo/branches/moja_galaz

Powyższe polecenie tworzy nową gałąź o nazwie moja_galaz którą można dowolnie sobie rozwijać, testować, modyfikować według własnych potrzeb, a następnie, gdy przyjdzie odpowiedni czas/ochota, dołączyć do aktualnego systemu.

W podobny sposób tworzy się konkretne tagi (tagi zwyczajowo oznacza się wielkimi literami):

svn cp svn://repo/trunk svn://repo/tags/HOME_20071210_1

Utworzy to aktualny snapshot repozytorium w katalogu /tags/HOME_20071210_1 (ostatnia
cyfra oznacza rewizję w ciągu tego samego dnia - oczywiście schemat nazewnictwa jest umowny).

Po utworzeniu własnej gałęzi, powinniśmy się na nią przełączyć, ponieważ domyślnie ciągle pracujemy na poprzedniej wersji repozytorium. Do przełączania się między gałęziami służy polecenie sw (switch):

svn sw svn://repo/branches/moja_galaz

W tym momencie pracujemy już na naszej gałęzi, i wszelkie commity, zmiany etc będą się odnosić do naszej wersji.
Co dalej?

Podstawowe prace i rozwijanie systemu powinno odbywać się na gałęzi trunk, która w razie puszczania zmian na system produkcyjny, powinna zostać skopiowana do odpowiedniego tagu, a następnie zsynchronizowana. Pozostaje jeszcze jeden problem: jak połączyć zmiany dokonane na osobnej gałęzi z tym, co dzieje się w aktualnym drzewku?

Tutaj pomoże nam komenda merge. Załóżmy hipotetyczną sytuację:

W repozytorium, w gałęzi trunk, znajduje się plik index.php. Ma on zawartość:

<?php

include 'some_file.php';

?>

W tej chwili tworzymy osobnego brancha:

svn cp svn://repo/trunk svn://repo/branches/mysz1
svn sw svn://repo/branches/mysz1

Od tego momentu pracujemy już na branchu mysz1. Sprawdzić to możemy za pomocą
komendy info:

svn info
[...]
URL: svn://repo/branches/mysz1
[...]

Dokonujemy zmiany w pliku index.php, tak że zawiera on teraz:

<?php
include 'some_file.php';
echo date ('Ymdhis'); // branches/mysz1
?>

Wykonujemy commit pliku, po czym przenosimy się na trunka:

svn sw svn://repo/trunk
svn info
[...]
URL: svn://repo/trunk
[...]

Sprawdzamy zawartość pliku index.php:

svn cat index.php
<?php
include 'some_file.php';
?>

Dokonujemy zmian, żeby plik wyglądał tak:

<?php
include 'some_file.php';
print strftime ('%Y%m%d %H%M%S', time ()); // trunk
?>

Commit, i wracamy na mysz1:

svn sw svn://repo/branches/mysz1
svn info
[...]
URL: svn://repo/branches/mysz1
[...]
svn cat index.php
<?php
include 'some_file.php';
echo date ('Ymdhis'); // branches/mysz1
?>

No to teraz próbujemy nanieść zmiany z branches/mysz1 na główną gałąź systemu:

svn merge -r 6:HEAD svn://repo/branches/mysz1 .

(na końcu jest kropka).

Co znaczą poszczególne części, wyjaśniam poniżej:

svn merge

polecenie

-r 6:HEAD

wersje która mają zostać połączone: najpierw numer wersji na której aktualnie pracujemy (w tym wypadku 6), później wersji do której chcemy się uaktualnić (HEAD, oznaczający najbardziej aktualną wersję, ale może to również być liczba oznaczająca konkretną rewizję)

svn://repo/branches/mysz1

branch który łączymy z trunkiem

.

(kropka) aktualna ścieżka (równie dobrze mogło to być svn://repo/trunk)

W tym wypadku powstanie nam konflikt, który rozwiązujemy tradycyjnym sposobem (kasując, dodając i poprawiając konkretne linie), a na końcu, po rozwiązaniu wszystkich problemów, robimy tradycyjny commit.

Więcej informacji znaleźć można na:

• svnbook.org.
• WikiBooks.
]]> http://urzenia.net/351/sposob-pracy-na-subversion-branche-tagi-etc/feed/ http://urzenia.net/351/sposob-pracy-na-subversion-branche-tagi-etc/