Como verificar versões de CMS de maneira rápida e prática


Para verificar devemos baixar a seguinte ferramenta em um dos dois endereços abaixo:




Em seguida fazer o seguinte

root@appunix:˜#chmod +x

root@appunix:˜#./ -u logindeumacontanomeuserver

A saída deverá assemelhar-se com:

Latest Joomla: 1.5.23
Installed Version: 1.5.20
Installed Location: /home/logindeumacontanomeuserver/public_html/pathdocms/

Essa dica funciona para Joomla, WordPress, WHMCS e etc.

Mercurial 1.9 Lançado!


Mercurial é mais um “sistema de controle de versão de distribuição open-source, como o Git. Mercurial foi concebido para projetos de maior envergadura, mais provavelmente fora do alcance da web designers e desenvolvedores independentes. Isso não significa que as pequenas equipes desenvolvimento não podem ou não devem usá-lo. Mercurial é extremamente rápido, e com o desempenho como a característica mais importante. O nome “mercurial” é um adjetivo que significa “Relativo a ou que tenham características (eloquência, rapidez, inteligência) atribuído ao deus Mercúrio.”

Para além de ser muito rápido e escalável, Mercurial é um sistema muito mais simples do que Git. Não há por enquanto muitas funções para aprender, e as funções são semelhantes às de outros sistemas CVS. Ele também vem equipado com uma interface Web stand-alone e extensa documentação sobre compreensão Mercurial se você estiver utilizando um outro sistema.

1. Mercurial 1.9 (2011-07-01)

This is a regular feature release. See UpgradeNotes for some minor compatibility notes.

1.1. Major features

New fileset file matching support
Improved remote changeset discovery

New command server mode to improve application integration
Experimental generaldelta storage scheme
Experimental new http client library

1.2. Command changes

HGPLAIN: allow exceptions to plain mode, like i18n, via HGPLAINEXCEPT
manifest: add new option –all
aliases: add positional arguments to non-shell aliases

add: introduce a warning message for non-portable filenames (issue2756)
add: notify when adding a file that would cause a case-folding collision

bisect: new command to extend the bisect range (issue2690)
bookmarks: allow deactivating current bookmark with -i
bundle: update current bookmark to most recent revision on current branch
diff: make diff -c aware of revision sets

help: add -c/–command flag to only show command help (issue2799)
help: add -e/–extension switch to display extension help text

help: move hgignore man page into built-in help (issue2769)
http: correctly handle redirects from http to https
identify: list bookmarks for remote repositories
import: add –bypass option
paths: Add support for -q/–quiet
pushkey: add hooks for pushkey/listkeys
revset: add aliases
revset: add ^ and ~ operators from parentrevspec extension
revset: add a revset command to get bisect state
revset: add desc(string) to search in commit messages
revset: add follow(filename) to follow a filename’s history across copies
revset: introduce filelog() to emulate log’s fast path
revset: add a last() function

1.3. Web changes

add bookmarks listing to raw style and summary pages
support alternate logo url

add base link to file log for paper and coal styles (issue2452)
paper, coal: display diffstat on the changeset page
elapsed time calculation dynamic (javascript)
provide diffstat and summary on the changeset page

1.4. Extension changes

hgcia: handle URL like in notify (issue2406)

rebase: add -m/–message to rebase –collapse (issue2389)
Updating hgext.extdiff to use revsets
bash_completion: enable alias auto-complete
bugzilla: add XMLRPC interface
color: add support for terminfo-based attributes and color
convert/mtn: add support for using monotone’s “automate stdio” when available
convert/svn: stop using svn bindings when pushing to svn
convert: add bookmark support for hg and git backends
convert: add svnrev, svnpath and svnuuid template keywords
extdiff: add repository root as a variable
graphlog: support more log command features with revsets
keyword: convert a verbatim block to a field list
keyword: offer additional datefilters when the extension is enabled
mq: add a ‘mq()’ revset predicate that returns applied mq csets
notify: send changesets on ‘outgoing’ hook, updated doc
progress: add speed format
rebase: add –tool argument for specifying merge tool
rebase: allow for rebasing descendants onto ancestors on different named branches
record: add an option to backup all wc modifications
record: add qrefresh -i/–interactive
record: add white space diff options
record: alias qrecord to qnew -i/–interactive

1.5. Bug fixes

bookmarks: allow create/move bookmark without making it current (issue2788)

bookmarks: do not forward merged bookmark (issue1877)

changegroup: do not count closed new heads (issue2697)

config: handle comment lines in continuations (issue2854)

dispatch: propagate ui command options to the local ui (issue2523)

eol: make the hook check all new heads, not only tip (issue2666)

grep: don’t print data from binary files for matches (issue2614)

http: report unexpected unparsable push responses (issue2777)
httprepo: handle large lengths by bypassing the len() operator

httprepo: long arguments support (issue2126)

httprepo: proper handling of invalid responses without content-type (issue2019)

httprepo: send URL redirection notices to stderr (issue2828)

localrepo: don’t add deleted files to list of modified/added files (issue2761)

localrepo: ignore tags to unknown nodes (issue2750)

merge: drop resolve state for mergers with identical contents (issue2680)

patch: do not patch unknown files (issue752)

path_auditor: check filenames for basic platform validity (issue2755)

rebase: don’t mark file as removed if missing in parent’s manifest (issue2725)

rebase: preserve mq series order after rebasing (issue2849)

rebase: restore mq guards after rebasing (issue2107)

revset: report a parse error if a revset is not parsed completely (issue2654)

scmutil: improve path calculation for install-relative RC files (issue2841)

set NOT_CONTENT_INDEXED on .hg dir (issue2694)

sslutil: fall back to commonName when no dNSName in subjectAltName (issue2798)

subrepo: be more careful with deletions of .hgsub and .hgsubstate (issue2844)

subrepo: make stdin for svn a pipe for non-interactive use (issue2759)

subrepo: svn abort now depends on exit code (issue2833)

subrepo: be smarter about what’s an absolute path (issue2808)

svn subrepo: attempt work around obstructed checkouts (issue2752)

svn subrepos: work around checkout obstructions (issue2752)

tags: catch more corruption during cache parsing (issue2779)

util: add Mac-specific check whether we’re in a GUI session (issue2553)

2. Mercurial 1.8.4 (2011-06-01)

This is a regular time-based bugfix release.

bookmarks: do not forward merged bookmark (issue1877)
changelog: convert user and desc from local encoding early
fix bookmarks rollback behavior
hgrc.5: document shell aliases

httprepo: proper handling of invalid responses without content-type (issue2019)

httprepo: send URL redirection notices to stderr (issue2828)

localrepo: don’t add deleted files to list of modified/added files (issue2761)

localrepo: ignore tags to unknown nodes (issue2750)

mq: strip extra whitespace from node ids in header (issue2790)

rebase: restore mq guards after rebasing (issue2107)
revset: expand help for contains predicate
revset: note case-insensitive matches in keyword and user
revset: note case-sensitive match in grep

revset: report a parse error if a revset is not parsed completely (issue2654)
revset: the name is optional for the tag predicate
simplemerge: do not allow binary files to abort an entire merge

strip: make it clear that –force discards changes (issue310)

subrepo: don’t crash when git .hgsubstate is empty (issue2716)

subrepo: make stdin for svn a pipe for non-interactive use (issue2759)
subrepo: respect non-default path for incoming/outgoing

subrepo: svn abort now depends on exit code (issue2833)

subrepo: use code from 71ea5b only if Python needs it (issue2795)

tags: catch more corruption during cache parsing (issue2779)

3. Mercurial 1.8.3 (2011-05-01)

This is a regular time-based bugfix release.

convert: make filemap prune useless branch closing revs (issue2774)

encoding: avoid localstr when a string can be encoded losslessly (issue2763)

extdiff: fix broken symlinks handling (issue1909)
help config: explain that config files do not exist by default
hgweb: add bookmark labels to gitweb theme
hgweb: add missing bookmarks definition to coal/map
hgweb: add missing bookmarks templates to atom/rss styles
hgweb: add separate bookmarks listing to gitweb theme
hgweb: add separate bookmarks listing to monoblue theme
hgweb: detect change based on changelog size too

hgweb: fix inconsistant display of graphlog (issue1706)
hgweb: fix typo and inactive link in page_nav and page_header of gitweb’s help
hgweb: fix typo in page-header of monoblue’s help template
hgweb: format page_nav of gitweb/error.tmpl and add missing links

rebase: don’t mark file as removed if missing in parent’s manifest (issue2725)
subrepo: handle svn tracked/unknown directory collisions

subrepo: prevent url normalization from removing // in ssh paths (issue2556)

subrepo: tell Subversion when we are non-interactive (issue2759)

url: use a regex to hide unsupported ssh passwords (issue2754)
zeroconf: notify the Zeroconf threads when hg exits

4. Mercurial 1.8.2 (2011-04-01)

This is a regular time-based bugfix release.

bookmarks: discard current bookmark if absent from the bookmarks (issue2692)
bookmarks: fix update of the current bookmark during rename

color: port to using ctypes (issue2687)

convert/svn: fix _iterfiles() output in root dir case (issue2647)
eol: do not abort when win32text is found, only warn
eol: use dirstate methods to clear dirstate
fix compiling of extensions for OS X and XCode 4.0
hgweb: add display of bookmarks for changelog and changeset
hgweb: add separate page with bookmarks listing

merge: avoid unlinking destination of merge when case changes (issue2715)
mq: do not let qrefresh write bad patch

pager: don’t page stderr if it’s being redirected (issue2541)

push/outgoing: print remote target path even if there’s an error (issue2561)
subrepo: recognize scp-style paths as git URLs

templates: widen the graph canvas (issue2683)

5. Mercurial 1.8.1 (2011-03-10)

This release backs out a behavior change for so-called ‘fast-forward’ merges on named branches.

annotate: rewrite to deal with crossed linkrevs (issue2682)
bookmark: fix invalidation of localrepo._bookmarkcurrent
cacert: improve error report when web.cacert file does not exist
contrib: update tcsh_completion for Mercurial 1.8
hgcia: accept “queued.” xmlrpc return as success
hgweb: fix filelog rss links generation

hgweb: use tip in gitweb/monoblue filelog rss links (issue2677)
merge: back out single-parent fast-forward merge

merge: drop resolve state for mergers with identical contents (issue2680)

merge: improve unresolved conflicts warning (issue2681)
mergetools: add alternate registry keys for 32bit apps on 64bit O/S
mq: forbid commit of merge involving mq patches

subrepo: backout 67fbe566eff1, –force requires svn >= 1.5
subrepo: don’t crash when git repo is missing
subrepo: handle svn tracked/unknown directory collisions

wix: drop bin/ folder from MSI installers (issue2673)

6. Mercurial 1.8 (2011-03-01)

6.1. Core

Bookmarks are now a core feature (see UpgradeNotes)

New listfile: pattern-matching (patterns)
Revset syntax supported by most commands
Performance improvements for reading large repository indexes
Certificate validation for HTTPS proxies

6.2. Subrepos

New support for git subrepos
Various improvements to merge, update, and commit logic

6.3. Windows

Numerous robustness improvements for quirks in Windows file handling

Now uses the native ctypes module rather than PyWin32

6.4. Extensions

eol: filter aliases for compatibility with win32text

mq: –exact option for qpush
mq: various robustness improvements
progress: remaining time estimates

7. Mercurial 1.7.5 (2011-02-01)

This is a quick bugfix release to include some fixes accidentally dropped from 1.7.4.

subrepo: fix update -C with svn subrepos when cwd != repo.root
subrepo: make update -C clean the working directory for svn subrepos
url: add –insecure option to bypass verification of ssl certificates
win32mbcs: Fix typo in documentation

8. Mercurial 1.7.4 (2011-02-01)

This is a scheduled bugfix release that smooths out some of the rough edged introduced with 1.7.3’s HTTPS certificate verification.

bookmarks: always write undo file
bookmarks: respect rollbacks dryrun parameter
hgrc.5: mention that web.cacerts are run through util.expandpath

opener: force copy on ‘a’ppend if nlinks() returns 0 (issue1922)
subrepo: compare svn subrepo state to last committed revision
subrepo: do not report known files inside repositories as unknown

url: ‘ssh known host’-like checking of fingerprints of HTTPS certificates (see CACertificates)
url: check subjectAltName when verifying ssl certificate
url: expand path for web.cacerts

url: fix UnicodeDecodeError on certificate verification error
win32: add cacert.pem file to Inno Setup installer

win32: win32console.GetStdHandle() can return None

9. Mercurial 1.7.3 (2011-01-01)

This is a scheduled bugfix release.

archive: don’t set gzip filename header when there’s no filename

checknlink: use two testfiles (issue2543)

churn: ignore trailing and leading spaces (issue2546)
date: fix matching of underspecified date ranges
eol: improve help on whether EOLs are changed in working copy or repository
fncachestore: copy dh directory before the manifest
hgweb: abort if config file isn’t found
hook: assume relative path to hook is given from repo root
hook: fix import path handling for repo=None
https: use web.cacerts configuration from local repo to validate remote repo

https: warn when server certificate isn’t verified (see CACertificates)
keyword: copy: when copied source is a symlink, follow it
patch: write .rej files without rewriting EOLs

strip: typo bugfix related to ‘–nobackup -> –no-backup’ rename (issue2377)

tag: abort if not at a branch head (issue2552)
tag: don’t check .hgtags status if –local passed

tag: fix uncommitted merge check and error message (issue2542)

util: fix ellipsis() not to break multi-byte sequence (issue2564)
util: work around behavior change in Python 2.7.1

windows.rename: eliminate temp name race (issue2571)

wix: add an ssl certificate file to the WiX installers (see CACertificates)

10. Mercurial 1.7.2 (2010-12-01)

This is a scheduled bugfix release.

checknlink: return False if .hgtmp file preexists (issue2517)

commit: search both parents for missing copy revision (issue2484)
context: walk both parents for workingctx.ancestors()
convert/svn: fix changed files list upon directory replacements

hgwebdir: fix incorrect index generation for invalid paths (issue2023)
keyword: copy: when copied source is a symlink, follow it

mq: ignore subrepos (issue2499)
rebase: support –detach when null is common ancestor
subrepo: fix removing read-only svn files on Windows
subrepo: handle missing subrepo spec file as removed
subrepo: prune empty directories when removing svn subrepo
subrepo: use subprocess directly to avoid python 2.6 bug

util: do not crash on revisions with negative timestamp (issue2513)

util: do not recurse in makedirs if name is ” (issue2528)
win32mbcs: use extsetup() to wrap functions only once
wix: add support for x64 native MSI packages

11. Mercurial 1.7.1 (2010-11-15)

This is an unscheduled bugfix release. 1.7 clients broke support for pushing bookmarks with HTTP.

alias: fall back to normal error handling for ambigious commands (issue2475)

bundlerepository: get rid of temporary bundle files (issue2478)
bundlerepository: test self.tempfile field, not tempfile module

eol: exclude .hgtags file from eol translation (issue2493)

log: fix log -rREV FILE when REV isnt the last filerev (issue2492)

opener: check hardlink count reporting (issue1866)

pushkey: force HTTP POST on push and add tests (issue2489)
revlog: fix descendants() if nullrev is in revs

subrepo: test & fix svn subrepo removal

win32: remove try-catch block of GetModuleFileNameEx (issue2480)

12. Mercurial 1.7 (2010-11-01)

12.1. Core

filelog: improve cmp performances (issue2273)

patch: don’t strip ‘#’ lines from patch descriptions (issue2417)
patch: when native patching fails (ui.patch is not set), don’t retry with an external tool
setup/hg: always load Mercurial from where it was installed.
setup: user-friendly error message if Python headers are missing

store: new unsupported and experimental parentdelta format (see UpgradeNotes)

store: encode first period or space in filenames (issue1713)

url: expand environment variables in [auth] settings (issue2328)

url: check validity (notBefore/notAfter) using OpenSSL (issue2407)

12.2. Commands

addremove: use similarity 100 by default
alias: add support for shell command aliases starting with ‘!’ (see [alias] in hgrc(5))
backout: add –tool argument for specifying merge tool
backout: backout linearly by default instead of branching and merging (use –merge to get the former behaviour)

dispatch: properly handle relative path aliases used with -R (issue2376)
init: expand destination url as a configured paths

log: do not –follow file that is deleted and recreated later (issue732)
merge: don’t detect copies as “divergent renames”, make diagnostic message more helpful
merge: add –tool argument to merge and resolve

merge: handle no file parent in backwards merge (issue2364)

tags: do not fail if tags.cache is corrupted (issue2444)
templater: add “hex” filter and “children” keywords (see hg help templating)

12.3. Subrepos

support remapping of subrepository source paths (see [subpaths] in hgrc(5))
make add, diff, incoming, outgoing and status commands recurse into subrepos with –subrepos/-S
subrepo: add support for ‘hg archive’

subrepo: fix status check on SVN subrepos (issue2445)

12.4. Revsets

add id() and rev() to allow explicit references to changes by hash or rev (see hg help revsets)
add min() function to complement max()
add present() function to avoid lookup errors on possibly missing changesets
rename tagged() to tag() and allow it to take an optional tag name
strip: add revsets support

add revsets support to bisect and update (issue1993)
bookmarks: add a bookmark([name]) revset for referencing bookmarks
transplant: add a transplanted(set) revset to get transplanted revisions

12.5. hgweb

add a help view for accessing the built-in documentation (see help link in hg serve)
let HTTPS serve use more compatible but less secure encryption

support very simple caching model (issue1845)

12.6. Extensions

color: better support for branches and mq guards

convert: handle closed branch heads in hg-hg conversion (issue2185)

convert: support darcs changelogs with bytes 0x7F-0xFF (issue2411)

convert: deprecate –authors in preference for –authormap

graphlog: support header and footer templates when using styles (issue2395)
keyword: do not expand at all during diff
keyword: support copy and rename

mq: extend support for the –mq argument to extension commands

mq: save qrefresh message for easy recovery in case it fails (issue2062)

mq: support hg qimport –existing –name renametothis thatexistingpatch, fix –force case on Windows
mq/qqueue: support renaming of active queue

mq/qqueue: add –purge option to delete a queue and its patches

pager: add global –pager= option

patchbomb: add –confirm option to show series details and ask for confirmation
patchbomb: let diffstat prompt only once with complete summary
progress: support rebase and patchbomb
rebase: re-add patches to mq repo after rebase

strip: add –keep flag to avoid modifying working directory during strip

strip: rename –nobackup option to –no-backup (issue2377)
strip: support stripping multiple revisions

12.7. contrib

mergetools.hgrc: add vimdiff
zsh completion: support bookmarks and patchbomb extensions
zsh completion: add qpush –move option

12.8. Windows

64-bit Inno Setup installer

handle spaces in path to Python (issue2074)

How to sobre como usar o Subversion (usuário)



Lancei este tutorial sobre o Subversion, originalmente, no dia 30 de maio de 2005 ainda pelo PATUX – Projeto de Aprendizado Tecnológico Universitário, na Universidade de Brasília (UnB), a partir de traduções e adaptações do manual oficial do mesmo ( Tinha como objetivo explicar o funcionamento deste sistema de versionamento (com documentação deficitária, em português, à época), e ensinar os membros do projeto a acessar os repositórios e contribuir para o desenvolvimento de software livre.Desde então, muita coisa mudou: o projeto terminou, o Subversion (que na período estava na versão 1.0.8 e era visto com certa desconfiança em relação ao já estabelecido CVS) já chegou à versão 1.5.4, vários novos front-ends foram lançados, suporte às mais populares IDEs (Eclipse, Visual Studio, entre outras) foi adicionado e, não menos importante (pelo menos para mim :P), pude alcançar um sonho particular: trabalhar e liderar conjuntamente uma empresa que verdadeiramente representa e trabalha em prol do software livre, a PWSys – Soluções em Tecnologia.

Assim sendo, creio ser de grande valia o relançamento deste documento, revisado e generalizado para utilização em cenários menos específicos que os que imaginei inicialmente. Reforça, ainda, a posição de comprometimento da PWSys com relação ao software livre e sua comunidade: outros documentos como este serão lançados, estando dispostos para auxiliar a propagação da cultura open source no Brasil.

Dito isso, sigam com o prefácio original deste tutorial.

Este tutorial visa dar uma introdução rápida sobre como utilizar o sistema de controle de versões Subversion. Este tutorial consistirá basicamente de quatro capítulos (clique nos links para ir diretamente):

  1. O que é o Subversion?
  2. Conceitos básicos de versionamento
  3. Comandos do Subversion
  4. Front-ends
Espero que com o que for explicado aqui o leitor possa utilizar de pronto e sem maiores problemas qualquer repositório Subversion. Esta é uma leitura altamente recomendada para os iniciantes em sistemas de versionamento, porém se quiser obter mais informações consulte o site oficial do Subversion ( e o manual oficial (, que contém muito mais detalhes do que este documento. Quaisquer dúvidas ou sugestões busque diretamente o autor, em seu e-mail (
var prefix = ‘ma’ + ‘il’ + ‘to’;
var path = ‘hr’ + ‘ef’ + ‘=’;
var addy72051 = ‘fbscarel’ + ‘@’;
addy72051 = addy72051 + ‘pwsys’ + ‘.’ + ‘com’ + ‘.’ + ‘br’;
document.write( ‘<a ‘ + path + ‘” + prefix + ‘:’ + addy72051 + ‘’>’ );
document.write( addy72051 );
document.write( ‘</a>’ );
document.write( ‘<span style=’display: none;’>’ );
). Boa leitura!Felipe Scarel, 10 de dezembro de 2008.


Copyright (c)  2008  Felipe Brant Scarel e PWSys – Soluções em Tecnologia
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be read at

Histórico de Revisões

Versão Data Autor Comentários
1.1 2008-12-10 11:25:26 Felipe Scarel Novo prefácio, Reescrita do Cap. 4
1.0 2005-05-30 01:30:04 Felipe Scarel Versão inicial do documento

O que é o Subversion?

O Subversion é um sistema de controle de versões livre, ou opensource. Com “sistema de controle de versões” queremos dizer que ele é capaz de gerenciar arquivos e diretórios ao longo do tempo. Basicamente, os arquivos são guardados em um repositório central e são servidos aos clientes. Muito embora isto se assemelhe a um servidor de arquivos, a diferença fundamental do Subversion é que ele guarda todas as modificações feitas nos arquivos e diretórios ao longo do tempo. Isso nos permite recuperar versões antigas dos dados ou simplesmente verificar o histórico destes. Por este motivo, é comum pensar nos sistemas de versionamento como “máquinas do tempo”. Para compreender melhor o Subversion é interessante que conheçamos um pouco da sua história:

No mundo do software livre, desde o início fez-se necessária uma ferramenta que pudesse controlar o aparente “caos” com que os programas são desenvolvidos. Para que todos pudessem desenvolver simultaneamente e sem prejuízo à organização foram criadas ferramentas de versionamento livres, sendo a mais bem-sucedida delas o Concurrent Versioning System (CVS), que logo se tornou o padrão em projetos opensource, e assim permanece até hoje. E com toda a razão, pois o fato de ser software livre, ter um design não-restritivo e bom suporte a rede permitem que vários programadores ao redor do mundo compartilhem seu código e construam softwares em conjunto. Porém, dada a sua idade, o CVS está se tornando ultrapassado, e muitos recursos modernos dos sistemas de versionamento não podem nele ser encontrados.

No início de 2000, a CollabNet ( comecou a buscar programadores para desenvolver um substituto ao CVS, que pudesse implementar o que ele apresenta de melhor mas sem copiar suas falhas mais evidentes. Eles então buscaram Karl Fogel (também um dos autores do livro do Subversion), que já vinha discutindo idéias semelhantes com seu amigo Jim Blandy. Este último inclusive já havia tido não apenas a idéia do nome “Subversion” bem como feito o layout básico de um repositório Subversion. Chamado pela CollabNet, Karl imediatamente foi trabalhar no projeto e Jim fez com que sua companhia, a conhecida Red Hat, praticamente o doasse ao projeto. Fortalecidos ainda pela contratação de Ben Collins-Sussman, eles iniciaram a codificação, e, após catorze meses, mais precisamente a 31 de Agosto de 2001, o Subversion passou a versionar seu próprio código e tornou-se uma realidade.

Muito embora os sistemas de versionamento, e por conseguinte o Subversion, sejam mais comumente usados para auxiliar programadores em seu desenvolvimento, é importate frisar que o Subversion não é limitado a ajudar programadores e pode ser utilizado para versionar qualquer tipo de dado. Para esclarecer os conceitos por trás dos sistemas de versionamento leia o próximo capítulo, que tratará precisamente deste tema. Se já estiver acostumado com estes conceitos e quiser apenas ver como o Subversion os implementa, pode seguir diretamente para o capítulo 3. Caso queira começar realmente rápido, mas provavelmente sem uma base teórica necessária, siga para o capítulo 4.

Conceitos Básicos de Versionamento

O Subversion é um sistema centralizado para compartilhar informações e dados. Ele é baseado em um repositório central, onde os dados ficam guardados sob a forma típica de uma árvore de arquivos e diretórios. Um número qualquer de clientes conectam-se ao repositório e lêem (recebendo as informações dos outros) ou escrevem (disponibilizando a informação aos demais) nestes dados. Até o momento isto não seria muito diferente de um servidor de arquivos normal, mas como foi explicado no primeiro capítulo, o Subversion tem a capacidade de guardar todas as alterações feitas aos arquivos, permitindo que elas sejam observadas, comparadas entre si, e eventualmente sobrescritas umas sobre as outras.Já sabemos o principal objetivo dos sistemas de versionamento. Porém, como faríamos para que todos pudessem trabalhar colaborativamente mas sem que ocorresse uma eventual sobrescrita, acidental, em nosso repositório? Vamos primeiramente apresentar o problema:

  • Suponhamos que dois usuários leiam as informações do repositório e iniciem a fazer modificações para posteriormente submeter suas contribuições. Se um usuário mandar suas modificações, e, logo depois, o outro também tiver a mesma idéia, o que ocorrerá é que as modificações do primeiro usuário não serão visualizadas ou aproveitadas, pois serão substituídas pelas alterações do segundo (uma vez que o padrão é visualizar a versão mais recente).

Para este problema temos duas soluções que são largamente utilizadas pelos sistemas de versionamento: a “Lock-Modify-Unlock” (Trancar-Modificar-Destrancar) e a “Copy-Modify-Merge” (Copiar-Modificar-Unir). Vamos apresentar separadamente cada uma delas:

  • “Lock-Modify-Unlock”:

Muitos sistemas de versionamento utilizam esta solução, que consiste basicamente em um sistema  parecido com o aluguel de livros em uma biblioteca: um usuário tranca o arquivo para edição, e enquanto ele faz suas modificações os demais não podem acessar o arquivo para escrita; se tentarem fazê-lo, o servidor irá negar a requisição. Logo após o primeiro usuário encerrar sua edição, ele irá destrancar o arquivo, e agora sim os demais poderão acessá-lo. Os problemas desta solução logo aparecem, pois ela é muito restritiva: se o primeiro usuário, por exemplo, sair de férias e esquecer o arquivo trancado, os demais terão que esperar até que ele volte ou contatar um administrador do sistema, o que não é desejável. Outro fator: suponhamos que dois usuário queiram editar o mesmo arquivo; isto não será um problema se um deles quiser editar o começo do arquivo e o outro quiser editar o final deste, e neste caso a solução tornaria o processo burocrático. Finalmente, esta solução cria um falso senso de segurança, pois se dois usuários trancarem arquivos diferentes, porém dependentes entre si, eles poderão modificá-los de forma a torná-los incompatíveis. Neste caso o sistema não teve poder para impedir que tal fato prejudicial ocorresse.

  • “Copy-Modify-Merge”:
O Subversion, CVS, e outros sistemas de versionamento preferem utilizar esta solução como uma alternativa ao trancamento dos arquivos. Neste modelo, cada usuário contata o repositório e copia para si a chamada “working copy”, que é uma cópia fiel da estrutura de arquivos e diretórios do servidor. Esses usuários trabalham em suas cópias particulares em paralelo, e finalmente suas modificações são unidas em uma versão final. Na maioria das vezes o repositório cuida do trabalho de fazer a união ocorrer corretamente, mas em última instância um ser humano deve cuidar desse processo. Na prática, suponhamos que dois usuários obtivessem working copies para si e comecassem a editá-las. Se um deles submeter suas modificações primeiro, quando o outro tentar mandar suas alterações o repositório lhe retornará um erro de “out-of-date” (arquivo antigo). Neste caso, o usuário receberá uma cópia do arquivo novo e deverá comparar esta nova versão com a sua, alterada localmente. Há uma boa chance de que as modificações não sejam conflitantes, e ele então poderá unir suas modificações com as de seu colaborador e submeter uma nova versão, com ambas as contribuições. Mas e se as alterações forem conflitantes? Como o próprio nome indica, nesse caso temos um “conflict” (conflito), e este deverá ser resolvido pelo usuário (uma vez que o programa não é capaz de tomar as decisões inteligentemente). Após resolver o conflito preexistente, possivelmente após uma conversa com o outro usuário, ele poderá então mandar a versão final e funcional.

O modelo utilizado pelo Subversion pode parecer caótico, mas quando vamos observá-lo mais de perto veremos que ele funciona de forma transparente; conflitos são infrequentes, e, quando ocorrem, são resolvidos rapidamente. Isso depende, contudo, de uma comunidade comunicativa e responsiva.

Comandos do Subversion

Vamos ver agora o Subversion em ação. Utilizaremos nos exemplos o cliente de linha de comando do Subversion, “svn”. No quarto capítulo apresentarei ainda alguns clientes gráficos do Subversion para poupar aqueles de vocês que não apreciam a interface de texto.

Primeiramente, suponhamos que iremos acessar um repositório exemplo. Vamos cuidar então da primeira parte, que será obter nossa working copy. Talvez fosse uma boa idéia ver a estrutura de diretórios do repositório exemplo na web, através de um visualizador como o WebSVN; digamos que a estrutura dos diretórios no servidor fosse a seguinte:

. exemplo/
. tags/
. branches/
. trunk/
. outros/
. x/
. y/
. z/

Vamos começar então com o comando mais importante de todos – como obter ajuda:

[shell]$ svn help

O comando acima mostraria todos os complementos possíveis ao “svn”, e poderíamos então descobrir qual comando é o mais apropriado para o nosso problema. Supondo agora que gostaríamos de obter uma working copy do repositório exemplo, digitaríamos então o seguinte comando:

[shell]$ svn checkout
A  exemplo
A  exemplo/tags
A  exemplo/branches
A  exemplo/trunk
A  exemplo/trunk/README
Checked out revision 1.

Este comando faria o checkout, ou cópia, da pasta “exemplo”, com todo o seu conteúdo, para o diretório atual. Isto quer dizer que, com este comando, obteríamos uma working copy para edição local, possibilitando-nos que trabalhássemos nela de pronto.

Podemos observar naquela última linha “Checked out revision 1″; vejamos o que ela exatamente quer nos dizer: ela nos informa que acabamos de fazer o checkout (ou cópia) dos arquivos do servidor pertencentes à revisão 1. Quando dizemos “revisão 1″, estamos nos referindo ao estado exato do repositório quando este se encontrava na referida revisão 1. Após alguém mandar alterações ao repositório, este passará à revisão 2, que será a mais recente (também conhecida como HEAD). Mas a revisão 1 ainda estará lá, e podemos vê-la ou recuperá-la com os comandos nativos do subversion, normalmente adicionando o switch “-r” ou “–revision”.

Podemos nos referir às revisões de três formas: a mais comum é através do número, que é único e crescente (como em “revision 1″); outra forma é através de palavras-chave que o Subversion nos fornece, como por exemplo HEAD (que se refere à revisão mais recente no repositório); finalmente, podemos nos utilizar ainda de datas em formatos predefinidos.

Expliquemos ainda a estrutura de diretórios dividida em trunk/, branches/ e tags/, largamente utilizada como padrão em repositórios: o diretório trunk/ contém a linha principal de desenvolvimento do projeto, e é nela que boa parte do código é desenvolvido. Pode ser necessário, no entanto, que se desenvolva uma nova capacidade ou característica de um programa, por exemplo. Tal desenvolvimento potencialmente tornaria o código da linha trunk/ instável, e, para evitar esse fato criaríamos um branch do projeto, focado unicamente em desenvolver essa característica específica que seria posteriormente portada de volta à árvore trunk/. Esta é superficialmente a função do diretório branches/.

É também perfeitamente possível que um programa, documento, etc, chegue em um nível de estabilidade tal que poderia ser liberado ao público e no qual não seria desejável nenhuma alteração. Essa é a função do diretório tags/, no qual residem as denominadas versões “estáveis” do projeto em questão.

Retornando aos comandos do Subversion, suponhamos agora que você deixou sua working copy parada por uns tempos e agora resolveu voltar a trabalhar nela. É possível, na verdade provável, que o estado do repositório tenha sido alterado desde sua última conexão. Para trabalhar em cima das versões mais recentes, é necessário que baixemos as modificações, e o faremos através do svn update:

[shell]$ svn update
U  exemplo/trunk/README
U  exemplo/trunk/novo.txt
Updated to revision 2.

Este comando deverá ser executado sob o diretório em que se encontra a working copy, obviamente. Ele irá buscar no servidor as modificações ocorridas em relação à versão local e aplicá-las de imediato.

A esta altura você deve ter notado as letras que apareceram nos últimos comando, A e U. Mas o que elas querem dizer? Vamos ver a seguir:

  • U: o arquivo foi “Updated” (atualizado) a partir do servidor
  • A: o arquivo ou diretório foi “Added” (adicionado) à sua working copy
  • D: o arquivo ou diretório foi “Deleted” (deletado) da sua working copy
  • R: o arquivo ou diretório foi “Replaced” (substituído) em sua working copy, ou seja, um elemento foi deletado e posteriormente outro com o mesmo nome foi adicionado; embora tenham o mesmo nome o repositório consegue percebê-los como arquivos diferentes
  • G: o arquivo no servidor recebeu alterações, mas sua cópia local tinha as suas modificações; ou as alterações não interceptavam ou eram idênticas às suas, então o Subversion conseguiu colocá-las em  estado de “merGed” (união) sem problemas
  • C: o arquivo recebeu alterações “Conflicting” (conflitantes) com as suas, ou seja, na mesma seção do arquivo; trataremos deste caso mais adiante no capítulo

Agora que já temos nossa working copy, podemos começar a trabalhar nela. Temos a possibilidade de fazer dois tipos de mudança: em arquivos específicos ou em diretórios (adicionando e removendo arquivos, por exemplo). No primeiro caso, não é necessário informar o Subversion com algum comando específico, pois ele será capaz de perceber quais arquivos foram mudados e submeter essas alterações ao servidor. Já no segundo caso, poderemos usar um dos quatro comandos básicos para manipulação de arquivos, explicados abaixo:

  • svn add

[shell]$ svn add novo.txt
A novo.txt

Este comando irá adicionar o arquivo “novo.txt” ao sistema de controle de versões, e ele também passará a ser versionado pelo repositório Subversion. Isto quer dizer que o arquivo existia para o seu computador mas era ignorado pelo Subversion, e, ao usar o “svn add”, você informou o Subversion que ele deve agora ser versionado. Se fosse um diretório, ele e todos os seus arquivos subjacentes seriam também adicionados. Vale lembrar que este passo não é opcional: não basta criar o arquivo, o “svn add” é fundamental.

  • svn delete

[shell]$ svn delete novo.txt
D novo.txt

Este outro comando irá agendar “novo.txt” para deleção do repositório. Se este fosse um arquivo ou link simbólico, ele seria imediatamente deletado da sua working copy; se fosse um diretório, seria deletado apenas após mandarmos as alterações ao servidor. É importante frisar que, após mandarmos as mudanças de volta ao repositório, o arquivo será deletado apenas da revisão mais recente, mas ainda estará presente nas revisões anteriores.

  • svn copy

[shell]$ svn copy novo.txt velho.txt
A velho.txt

O “svn copy” acima irá copiar o arquivo “novo.txt”, juntamente com seu histórico, para um arquivo denominado “velho.txt”, que será imediatamente agendade para adição no repositório. O histórico do arquivo criado irá indicar que ele é proveniente de um outro.

  • svn move

[shell]$ svn move novo.txt velho.txt
A velho.txt
D novo.txt

Como pode ser visto acima, o “svn move” irá apenas fazer o papel de “svn copy” e “svn delete” em um só comando; ele irá copiar o arquivo com um outro nome e depois irá deletar o original, o que seria basicamente o equivalente a renomear um arquivo qualquer.

Agora que já editamos o que fosse necessário ou desejável, seria interessante verificar o que foi modificado antes de mandar nossas alterações ao repositório, criando uma nova revisão. Podemos fazê-lo através do svn status (certamente o comando que você deve, espera-se, mais utilizar no Subversion):

[shell]$ svn status
M      bar.c
?      foo.o
!      qq_dir
I      .screenrc
A  +   moved_dir
M  +   moved_dir/README
D      outros/teste.c
A      outros/calc/soma.h
C      outros/calc/divide.c
R      xyz.c
S  outros/game

Temos acima um possível exemplo de saída do comando “svn status”, que nos ajudará a explicar os status mais importantes a serem compreendidos. Na primeira coluna, temos:

  • A: o arquivo/diretório foi agendado para adição no repositório
  • C: o arquivo está em estado de conflito e será necessário resolvê-lo antes de mandar as alterações ao servidor
  • D: o arquivo/diretório foi agendado para deleção no repositório
  • M: o conteúdo do arquivo foi modificado
  • R: o arquivo foi agendado para substituição no repositório, com o mesmo nome de um que foi deletado
  • ?: o arquivo em questão não está sob controle de versão (possivelmente foi criado e não foi utilizado o “svn add”)
  • !: o arquivo não está presente por algum motivo, possivelmente tendo sido deletado sem o uso de um comando Subversion
  • I: o arquivo foi configurado para ser ignorado pelo sistema de controle de versões;

Na coluna seguinte poderemos ver um “+” ou não, indicando que um arquivo foi agendado para adição no repositório com a preservação de seu histórico. Isso provavelmente nos dirá que ele é proveniente de uma cópia com o “svn copy” (A+), ou, além de ter sido copiado também foi modificado localmente (M+). A última coluna nos dirá se um arquivo ou diretório foi deslocado do caminho do restante de sua working copy, com o comando “svn switch”, para um branch ou tag (explicados mais à frente). Para a referência completa dos possíveis outputs do “svn status” consulte o manual oficial do Subversion.

Adicionando o switch “-u” ou “–show-updates” ao “svn status”, juntamente com a opção “-v” ou “–verbose” (para maior detalhamento), ele irá contatar o servidor e comparar suas modificações com as revisões que lá se encontram, e irá informar sobre arquivos antigos (out-of-date):

[shell]$ svn status –show-updates –verbose
M      *        44        23    john      README
M               44        20    david     bar.c
*        44        35    susan     outros/teste.c
Status against revision:   46

Os asteriscos acima nos indicam que caso fosse utilizado o “svn update” neste ponto os arquivos “README” e “teste.c” receberiam modificações. Isto quer dizer que nossa revisão local está desatualizada e devemos fazer um update para receber as modificações nestes arquivos e conferir se estas conflitam com a versão local.

Digamos agora que queremos saber exatamente quais modificações fizemos aos arquivos antes de mandá-las ao servidor; esta seria uma boa hora para usar o svn diff, que mostrará as diferenças entre a nossa versão modificada e a versão obtida inicialmente (que fica no diretório oculto .svn):

[shell]$ svn diff
Index: teste.c
— teste.c (revision 3)
+++ teste.c (working copy)
@@ -1,7 +1,12 @@

int main(void) {
–  printf(“Ola mundon”);
+  printf(“Ola de novo mundon”);
return 0;

As modificações são mostradas em formato diff unificado, sendo as linhas adicionadas mostradas com um “+” antes e as deletadas mostradas com um “-”. É interessante notar que podemos facilmente produzir um patch (arquivo incluido apenas as modificações em um arquivo) com o auxílio do svn diff, como no exemplo abaixo:

[shell]$ svn diff > patchfile

Suponhamos então que você descobrisse que as suas alterações ao “teste.c” acima foram feitas por engano, e que portanto você gostaria de retornar este arquivo ao seu estado original; é um bom momento para utilizar o svn revert:

$ svn revert teste.c
Reverted ‘teste.c’

Isto retornará nosso arquivo “teste.c” ao seu estado original, quando fizemos nosso último checkout a partir do repositório. É um processo semelhante ao utilizado para recuperar eventuais modificações mandadas ao servidor mas que foram desastrosas.

Neste último caso, bastaria dar um checkout em uma revisão anterior e funcional (usando o switch “–revision”), e posteriormente mandar esta revisão correta ao servidor novamente, se tornando HEAD.

Vale lembrar ainda que estes trás últimos comandos, muito embora lidem diretamente com os arquivos antigos, dispensam uma conexão com a rede, pois o Subversion inteligentemente mantém uma cópia imodificada dos arquivo em uma pasta oculta “.svn”, e depois apenas compara o conteúdo desta pasta com as modificações feitas pelo usuário.

Já estamos praticamente finalizados com nossa tarefa diária: sabemos adicionar e deletar arquivos, verificar as modificações feitas, conferir se estas estão desatualizadas e resolver conflitos simples, processo automatizado pelo Subversion. Mas ainda resta uma dúvida: e se nossas modificações não resultarem em um conflito simples, no qual nossa alteração intercepta diretamente a de um colaborador? Vejamos a saída de um svn update que causará esse problema:

[shell]$ svn update
C  teste.c
Updated to revision 46.

As letras U e G caem naqueles casos estudados anteriormente: no primeiro foi feito um update simples e no segundo o Subversion conseguiu unir as modificações locais e remotas sem maiores problemas. Já a terceira ocorrência poderá nos causar um problema, pois indica um conflito (C). Neste caso surgirão três arquivos no diretório de trabalho: [ARQUIVO].mine (com as alterações locais), [ARQUIVO].r[OLD] (arquivo imodificado desde o último update) e [ARQUIVO].r[NEW] (o arquivo proveniente do update, diretamente do repositório). Serão ainda colocados marcadores de conflito no arquivo original, a fim de auxiliar o processo de análise. Poderemos resolver o conflito de três formas:

  • Unir os arquivos manualmente:

Pode parecer ameaçador, mas fazer a união dos arquivos é na verdade realmente simples: analisar-se-á as alterações feitas remotamente e estas serão comparadas às locais. O usuário deverá decidir qual delas é a melhor, ou então poderá juntar ambas as soluções. De qualquer maneira, é imprescindível que haja uma boa comunicação entre os colaboradores, pois seria conveniente que houvesse uma discussão entre eles para decidir o melhor caminho.

  • Escolher uma das opções:

Pode-se ainda optar por simplesmente copiar uma das soluções inteiramente, ou a local ou a remota. Nesse caso, bastaria um “cp” simples dos sistemas UNIX-like para resolver o conflito.

  • Descartar as edições locais:

Finalmente, é também possível perceber que as alterações feitas localmente não deveriam ser mandadas ao repositório. Neste último caso, bastaria um “svn revert” para encerrar o conflito e retornar os arquivos aos seus estados originais.

Uma vez resolvidos todos os conflitos, devemos informar o Subversion, e o faremos com o comando svn resolved:

[shell]$ svn resolved teste.c

Com este comando os arquivos extras que haviam sido criados serão excluídos e a condição de conflito desaparecerá. Agora sim poderemos mandar nossas modificações ao repositório (finalmente!), e o faremos com o comando svn commit:

[shell]$ svn commit -m “Algumas modificacoes simples no arquivo teste.c”
Sending        teste.c
Transmitting file data .
Committed revision 47.

O comando acima submeterá nossas modificações locais ao repositório, e a mensagem passada através do switch “–message” ou “-m” será a mensagem de log do commit. É importantíssimo que essa mensagem descreva precisamente o que foi modificado, assim ficará muito mais fácil recuperar o repositório após um engano, além de ajudar os usuário a utilizar o sistema com mais eficiência. Essa mensagem pode ser ainda passada através de um arquivo, com o switch “–file”.

Existem ainda muitos outros comandos que este tutorial não cobriu, afinal o seu foco é de que seja uma fonte rápida para consulta e aprendizado. Dentre estes encontram-se comandos de pesquisa e administrativos. É altamente recomendada a leitura, complementar, do manual oficial do Subversion.


Desde a versão original deste documento, o número de front-ends disponíveis para o Subversion aumentou drasticamente, exigindo total reformulação desta seção. Aos programas descritos originalmente (RapidSVN, WebSVN e TortoiseSVN), juntaram-se vários outros dignos de nota e de usos variados, e que tornam esse sistema de controle de versão ainda mais interessante de ser utilizado. De clientes stand-alone até aqueles integrados ao desktop, passando por aplicações para browsing via web ou IDE, o número de opções para acessar e operar repositórios SVN é tanto que seria até injusto eleger alguns poucos para figurar neste tutorial.

Assim sendo, irei utilizar o mesmo approach da página de links do site oficial do Subversion ( por categorias, cada aplicação e um link para sua página será apresentado, bem como uma breve descrição do programa. Sem mais delongas, vamos à lista:

  1. Cornerstone: cliente gráfico Subversion para Mac OS X. Não é open source, mas possui versão trial gratuita disponível
  2. eSvn: cliente gráfico multiplataforma baseado em QT para o Subversion
  3. FSVS: rápido cliente de linha de comando para o Subversion centrado em implantação de software
  4. KDESvn: cliente Subeversion para o KDE
  5. QSvn: cliente gráfico multiplataforma para o Subversion
  6. RapidSVN: cliente gráfico multiplataforma para o Subversion
  7. RSVN: script Python que permite múltiplas operações de repositório em uma única transação atômica
  8. SmartSVN: cliente gráfico multiplataforma para o Subversion. Não é open source, mas está disponível em versões gratuita e comercial
  9. Subcommander: cliente gráfico multiplataforma para o Subversion, inclui ferramenta para merge textual
  10. SvnX: cliente gráfico multiplataforma para Mac OS X Panther
  11. Syncro SVN Client: cliente gráfico multiplataforma para o Subversion. Não é open source, mas possui versão trial disponível para Mac OS X, Windows e Linux
  12. WorkBench: ambiente de desenvolvimento multiplataforma utilizando Subversion, escrito em Python
  13. Versions: cliente gráfico Subversion para Mac OS X. Não é open source; requer licença comercial
  14. ZigVersion: interface Subversion para Mac OS X. Interface voltada a workflows típicos de programadores. Não é open source
  1. Cascade: driver de sistema de arquivos multiplataforma para o Subversion, tanto gráfico quanto em linha de comando. Também provê outras funcionalidades de alto nível. Não é open source; gratuito para uso pessoal
  2. KSvn: cliente Subversion para o KDE; um plugin para o Konqueror
  3. SCPlugin: integração Subversion para o Finder do Mac OS X
  4. TortoiseSVN: um cliente Subversion, implementado como extensão do shell do Windows
  • Plugins para IDEs (vale lembrar que muitas IDEs suportam o Subversion nativamente ou por plugins inclusos; esta seção lista os plugins não-inclusos com as IDEs)
  1. Aigenta Unified SCC: plugin Subversion/CVS para programas compatíveis com MSSCCI, incluindo o Microsoft Visual Studio e outros. Não é open source, mas possui versão trial gratuita disponível
  2. AnkhSVN: integração Subversion para o Microsoft Visual Studio
  3. CW Subversion: plugin VCS para o Metrowerks CodeWarrior
  4. Subclipse: plugin Subversion para o Eclipse
  5. Subversive: plugin Subversion para o Eclipse
  6. SVN SCC Proxy: plugin SCC para SVN. Este não é um projeto open source
  7. VisualSVN: integração Subversion para o Visual Studio .NET 2003, 2005 & 2008. Este é um produto comercial de código fechado
  8. WLW-SVN: extensão Subversion para o WebLogic Workshop (8.1.3/8.1.4)
  1. psvn.el: interface Subversion para o emacs
  2. Vcscommand.vim: plugin de integração CVS/SVN/SVK para o editor vim
  1. Trac: o Trac é um sistema web minimalista para gerenciamento de projetos e tracking de bugs e requisições. Ele provê uma interface ao sistema de controle de versões (Subversion), um Wiki integrado e funcionalidades de report
  2. Collaboa: browser de repositório e tracker de requisições, similar ao Trac
  1. SVN::Web
  2. ViewVC (previamente conhecido como ViewCVS)
  3. WebSVN
  4. Insurrection: Repositório em
  5. Chora
  6. SVN::RaWeb::Light
  7. FlexySvn
  8. perl_svn
  9. mod_svn_view
  10. bsSvnBrowser
  11. sventon
  12. WebClient for SVN


Espero que este documento tenha sido de ajuda para o seu aprendizado, leitor, e através dele estou certo de que foi possível aprender os passos fundamentais para um dia de trabalho completo em um repositório Subversion. Agradeço a leitura e boa utilização dos repositórios!


Descobrir nome da Distribuição em uso (mini-tuto)


É comun que cheguemos em algum lugar e encontremos um Gnu/Linux rodando turbinado ou até mesmo para um troubleshooting, nada melhor do que antes de “meter a mão” saibamos aonde estamos “pisando”.

Quer saber qual sua distro? Use:

dmesg | head -n 2

Se o comando acima não exibir a real distribuição tente:

uname -a

Se mesmo assim ainda não rolar (caso do Fedora), use:

cat /etc/issue

Este último deve cravar!

Abraços! ah… seguem meus resultados:

[root@localhost ~]# dmesg | head -n 2
Initializing cgroup subsys cpuset
Linux version (mockbuild@) (gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) ) #1 SMP Mon Aug 4 14:08:11 EDT 2008

[root@localhost ~]# cat /etc/issue
Fedora release 9 (Sulphur)
Kernel \r on an \m (\l)

[root@localhost ~]# uname -a
Linux localhost.localdomain #1 SMP Mon Aug 4 14:08:11 EDT 2008 i686 i686 i386 GNU/Linux
[root@localhost ~]#