<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Basic Subversion Repository Management</title>
	<atom:link href="http://avi.alkalay.net/2007/08/basic-subversion-repository-management.html/feed" rel="self" type="application/rss+xml" />
	<link>http://avi.alkalay.net/2007/08/basic-subversion-repository-management.html</link>
	<description>Digital Awareness and Flying Spirit</description>
	<pubDate>Fri, 25 Jul 2008 08:49:37 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: Thiago Galesi por e-mail</title>
		<link>http://avi.alkalay.net/2007/08/basic-subversion-repository-management.html#comment-113746</link>
		<dc:creator>Thiago Galesi por e-mail</dc:creator>
		<pubDate>Fri, 07 Sep 2007 18:25:00 +0000</pubDate>
		<guid isPermaLink="false">http://avi.alkalay.net/2007/08/basic-subversion-repository-management.html#comment-113746</guid>
		<description>Olá

(Desculpe, só vi agora o email)

No contexto de VCS (sistemas de controle de versão) :
Changeset é um conjunto de mudanças (em diversos arquivos), ao invés de simplesmente revisões de arquivo sem ligação umas em outras.

Ou, segundo a wikipedia: "Atomic commit is supported also by modern revision control systems and allows committing—uploading to the source—changes in multiple files (called a changeset) " (em http://en.wikipedia.org/wiki/Atomic_commit)

Coisa que todo sistema de controle de versão moderno deveria suportar. No caso do post, o Subversion suporta.

Um exemplo: tenho uma função definida num arquivo.h e com sua implementacao num arquivo.c, e, por exemplo, um parâmetro da função mudou (o que pede uma mudança nos dois arquivos).

Em um VCS sem changesets, o .h vai para uma versão, o .c vai para outra e é necessário um recursos externo para ligar as modificações. E se coloca uma versão do arquivo sem estar casada com a outra, já era.

No Subversion, você muda os dois arquivos, e faz checkin de ambos ao mesmo tempo (svn ci arquivo.h arquivo.c); o changeset inclui as duas mudanças, e são inseparáveis do ponto de vista do VCS. Ou seja, ou a mudança é incluída ou não, sem perigo de inconsistência.

Os processos de desenvolvimento do kernel linux e de muito outros projetos, tanto abertos como proprietários são baseados em Changesets (principalmente na forma de unified diff).

E ganha um doce quem descobrir o nome do sistema de controle de versão moderno que não suporta changesets nem unified diffs.¬¬

Atenciosamente

Thiago Galesi</description>
		<content:encoded><![CDATA[<p>Olá</p>
<p>(Desculpe, só vi agora o email)</p>
<p>No contexto de VCS (sistemas de controle de versão) :<br />
Changeset é um conjunto de mudanças (em diversos arquivos), ao invés de simplesmente revisões de arquivo sem ligação umas em outras.</p>
<p>Ou, segundo a wikipedia: &#8220;Atomic commit is supported also by modern revision control systems and allows committing—uploading to the source—changes in multiple files (called a changeset) &#8221; (em <a href="http://en.wikipedia.org/wiki/Atomic_commit" rel="nofollow" onclick="javascript:urchinTracker ('/outbound/comment/en.wikipedia.org');">http://en.wikipedia.org/wiki/Atomic_commit</a>)</p>
<p>Coisa que todo sistema de controle de versão moderno deveria suportar. No caso do post, o Subversion suporta.</p>
<p>Um exemplo: tenho uma função definida num arquivo.h e com sua implementacao num arquivo.c, e, por exemplo, um parâmetro da função mudou (o que pede uma mudança nos dois arquivos).</p>
<p>Em um VCS sem changesets, o .h vai para uma versão, o .c vai para outra e é necessário um recursos externo para ligar as modificações. E se coloca uma versão do arquivo sem estar casada com a outra, já era.</p>
<p>No Subversion, você muda os dois arquivos, e faz checkin de ambos ao mesmo tempo (svn ci arquivo.h arquivo.c); o changeset inclui as duas mudanças, e são inseparáveis do ponto de vista do VCS. Ou seja, ou a mudança é incluída ou não, sem perigo de inconsistência.</p>
<p>Os processos de desenvolvimento do kernel linux e de muito outros projetos, tanto abertos como proprietários são baseados em Changesets (principalmente na forma de unified diff).</p>
<p>E ganha um doce quem descobrir o nome do sistema de controle de versão moderno que não suporta changesets nem unified diffs.¬¬</p>
<p>Atenciosamente</p>
<p>Thiago Galesi</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tabgal</title>
		<link>http://avi.alkalay.net/2007/08/basic-subversion-repository-management.html#comment-72459</link>
		<dc:creator>Tabgal</dc:creator>
		<pubDate>Fri, 31 Aug 2007 14:10:30 +0000</pubDate>
		<guid isPermaLink="false">http://avi.alkalay.net/2007/08/basic-subversion-repository-management.html#comment-72459</guid>
		<description>And by the way: "Improve icon A"should be one changeset, "delete icon B"should be another changeset and so on...</description>
		<content:encoded><![CDATA[<p>And by the way: &#8220;Improve icon A&#8221;should be one changeset, &#8220;delete icon B&#8221;should be another changeset and so on&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: caio1982</title>
		<link>http://avi.alkalay.net/2007/08/basic-subversion-repository-management.html#comment-72430</link>
		<dc:creator>caio1982</dc:creator>
		<pubDate>Fri, 31 Aug 2007 12:26:58 +0000</pubDate>
		<guid isPermaLink="false">http://avi.alkalay.net/2007/08/basic-subversion-repository-management.html#comment-72430</guid>
		<description>&lt;em&gt;bash$ svn -m "Improved icon A, deleted icon B, added icon C" commit&lt;/em&gt;

That's really a bad idea. One of the worst problems with commits is useless log messages like that, no offense :-) I mean, Subversion already tells you what changed, what has beend removed from the repository and what exact lines you worked on, there's no need to repeat that (shortly) in the commit message.

You'd rather explain why you changed those lines, how you fixed a weird bug or logic and do things like pasting a link with the bug number from your BT, that actually helps.

Also, if you use scripts such as svn2log to create automatic ChangeLog files for your project, you'll ended up with a pretty much useless ChangeLog file.</description>
		<content:encoded><![CDATA[<p><em>bash$ svn -m &#8220;Improved icon A, deleted icon B, added icon C&#8221; commit</em></p>
<p>That&#8217;s really a bad idea. One of the worst problems with commits is useless log messages like that, no offense <img src='http://avi.alkalay.net/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> I mean, Subversion already tells you what changed, what has beend removed from the repository and what exact lines you worked on, there&#8217;s no need to repeat that (shortly) in the commit message.</p>
<p>You&#8217;d rather explain why you changed those lines, how you fixed a weird bug or logic and do things like pasting a link with the bug number from your BT, that actually helps.</p>
<p>Also, if you use scripts such as svn2log to create automatic ChangeLog files for your project, you&#8217;ll ended up with a pretty much useless ChangeLog file.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.367 seconds -->
