Comandos mais usados do svn

Estou criando esta lista pra gente ter sempre à mão os comandos mais usados do svn no terminal, de modo simples e compacto.

* Para mais comandos e detalhes: http://www.tigris.org/scdocs/ddUsingSVN_command-line

checkout (co)
add
del
move (mv)
status (st)
diff
log
revert

update (up)
resolved
commit (ci)


Esteja na pasta que foi realizado o checkout para executar os comandos.

checkout

Baixa o projeto
svn co http://svn.address.com/trunk dest_folder --username user

add

Adiciona um novo arquivo ao versionamento
svn add file

del

Remove um arquivo do versionamento

--keep-local mantém o arquivo localmente, porém fora do versionamento

svn del file --keep-local

moveRenomeia ou move um arquivo no versionamento (deletando o antigo e adicionando o novo)

svn mv orig dest

status

Visualiza se um arquivo será ou foi adicionado, deletado, ou modificado localmente ou no repositório

-u para ver modificações do repositório
svn st -u

diffVisualiza as alterações feitas no arquivo

svn diff file

logVisualiza a mensagem de commit do arquivo

svn log file

revertReverte a alteração local feita no arquivo

svn revert file

update

svn up

resolvedRemove o status de conflito do arquivo

svn resolved file

commitEnvia as alterações para o repositório

svn ci -m message

Resumão OSGI

http://www.springsource.org/training/osgi/online

Spring - DM Server -> Dinamic Modules Server

1-OSGi -> Sistema de modularização dinâmica para Java -> Modularização de verdade

Modular:
-Projetos (módulos), que são chamados de Bundles
-JAR files com meta-data
-Baseado em pacotes
-Versionamento de pacotes e bundles

Dinâmico:
-Adicionar, remover, startar e parar bundles em runtime
-Usa serviços compartilhados para compartilhar objetos, não apenas tipos

"Bundles usam JAR Manifest para meta-data" -> a configuração é feita no Manifest.mf dentro do META-INF

Por default um bundle não consegue enxergar as classes dos outros

Para que um suas classes (tipos) fiquem disponíveis para os outros bundles é necessário exportar seus pacotes

BOAS PRÁTICAS
-Separe as interfaces das implementações
*Coloque-os em pacotes diferentes
*Exporte apenas as API públicas e esconda os detalhes
*Exponha as implementações como serviços
-Versione seus pacotes
*Libere várias versões no mesmo runtime
*Clientes pegam a versão que eles precisarem

Para ter acesso aos tipos dos outros bundles é necessário importar os pacotes disponíveis (você pode especificar um range da versão que quer usar. Ex: "[1.0.0,2.0.0)" - incluindo a 1 e excluindo a 2)

Os containers OSGi têm um pequeno core e são leves
-Equinox (RI - eclipse)
-Apache Felix
-Knoplerfish

Bundles são instalados no container OSGi e têm um lifecicle
-Installed (faltando dependências)
-Resolved (parado, mas com as dependências satisfeitas)
-Starting
-Started (serviços disponíveis)
-Stopping
-Uninstalled (sai no restart)

Você deve disponibilizar os tipos (interface) através do manifest.mf e deve exportar os serviços em uma classe que estende org.osgi.framework.

BundleActivator.

Para utilizar o serviço você deve importar, no manifest.mf a classe que está disponível e, em um BundleActivator, recuperar a instância do serviço

2-OSGi + Spring

Simplifica o uso do OSGi através do applicationContext

Os arquivos do Spring ficam em META-INF/spring

namespace osgi

Você usa o bean de outro bundle como dependência e o Spring injeta (osgi:reference)

O Spring disponibiliza o serviço para você (osgi:service)

BOAS PRÁTICAS
-Separar arquivos normais de configuração do Spring dos arquivos de configuração do Spring-DM

3-Enterprise OSGi

OSGi não suporta aplicações web, então a Spring implementou isto no seu servidor DM

Não possui nenhuma das funcionalidades de EJB, JNDI, etc..

4-Modularização da aplicação

-Vertical
*Por funcinalidade
°Pedidos, Pagamentos, Vendas...
-Horizontal
*Por camadas
°Web, Repositório, Serviço...

Compartilhar infa-estrutura faz sentido
-DataSources
-TransactionManager
-JMS

Qual o tamanho de um Bundle?
-Responsabilidade definida
-Alta coesão
-Baixo acoplamento

Modularização horizontal tende a acoplar os módulos

5-Sumário

OSGi modulariza de verdade dinamicamente

Muitos benefícios em potencial, mas não são fáceis de se conseguir

OSGi é uma área que ainda está no início da evolução (2008) e novos produtos e padrões estarão surgindo