O grupo no qual você está postando é um grupo da Usenet. As mensagens postadas neste grupo farão com que o seu e-mail fique visível para qualquer pessoa na Internet
Estamos com um problema talvez até conceitual sobre controle de versão e gostaria de opiniões sobre a utilização em grandes projetos. Vamos ao nosso cenário atual.
Temos um repositório com 3 diretórios: - trunk: atualizações diárias dos desenvolvedores - branch: homologação/testes - tag: versões de produção
Ao ser lançada uma nova versão, é iniciado o processo de homologação do pacote no branch (1.0). Enquanto isso o desenvolvimento é continuado com novas implementações (trunk) para a futura versão 1.1. Ao ser detectado um problema em homologação (1.0 do branch), a correção deve ser feita pelo desenvolvedor, porém a versão do trunk já não é mais a mesma da que existe no branch.
Qual é a melhor forma de fazer a correção do problema encontrado na versão 1.0 do branch sem liberar as implementações feitas na versão 1.1 do trunk?
Se um desenvolvedor da equipe dar um revert para essa versão 1.0, fazer as correções e gravar no branch para novos testes já temos que também fazer a correção na versão que já está em desenvolvimento no trunk, dando trabalho dobrado (atualizar 2 arquivos).
O merge ajuda, mas nem tanto, pois acusará bastante diferença entre a versão corrigida (do branch) e a versão do trunk que continuou em desenvolvimento enquanto a versão 1.1 (do branch) era testada.
Alguma sugestão? Questionem caso a explicação não tenha ficado clara.
a melhor solução se chama StarTeam, da Borland. O suporte a diferentes releases permite um controle preciso do que deve e pode ser commitado em cada versão. Além de Integrar os CR (Change Request) diretamente com o controle de versão.
Em 03/07/08, William G. Comnisky <w.comni...@gmail.com> escreveu:
> Estamos com um problema talvez até conceitual sobre controle de versão > e gostaria de opiniões sobre a utilização em grandes projetos. Vamos > ao nosso cenário atual.
> Temos um repositório com 3 diretórios: > - trunk: atualizações diárias dos desenvolvedores > - branch: homologação/testes > - tag: versões de produção
> Ao ser lançada uma nova versão, é iniciado o processo de homologação > do pacote no branch (1.0). Enquanto isso o desenvolvimento é > continuado com novas implementações (trunk) para a futura versão 1.1. > Ao ser detectado um problema em homologação (1.0 do branch), a > correção deve ser feita pelo desenvolvedor, porém a versão do trunk já > não é mais a mesma da que existe no branch.
> Qual é a melhor forma de fazer a correção do problema encontrado na > versão 1.0 do branch sem liberar as implementações feitas na versão > 1.1 do trunk?
> Se um desenvolvedor da equipe dar um revert para essa versão 1.0, > fazer as correções e gravar no branch para novos testes já temos que > também fazer a correção na versão que já está em desenvolvimento no > trunk, dando trabalho dobrado (atualizar 2 arquivos).
> O merge ajuda, mas nem tanto, pois acusará bastante diferença entre a > versão corrigida (do branch) e a versão do trunk que continuou em > desenvolvimento enquanto a versão 1.1 (do branch) era testada.
> Alguma sugestão? Questionem caso a explicação não tenha ficado clara.
Valeu Erick, mas existe alguma solução sem utilizar algum software adicional? Ou então alguma opção open-source e principalmente para linux?
Esqueci de mencionar que nossos ambientes de desenvolvimento são linux.
O problema maior é de fazer duas vezes a mesma alteração em arquivos diferentes. Dependendo da quantidade de diferença entre ambas, o processo de merge fica extremamente demorado e suscetível a erros.
> a melhor solução se chama StarTeam, da Borland. O suporte a diferentes > releases permite um controle preciso do que deve e pode ser commitado em > cada versão. Além de Integrar os CR (Change Request) diretamente com o > controle de versão.
> Em 03/07/08, William G. Comnisky <w.comni...@gmail.com> escreveu:
>> Bom dia,
>> Estamos com um problema talvez até conceitual sobre controle de versão >> e gostaria de opiniões sobre a utilização em grandes projetos. Vamos >> ao nosso cenário atual.
>> Temos um repositório com 3 diretórios: >> - trunk: atualizações diárias dos desenvolvedores >> - branch: homologação/testes >> - tag: versões de produção
>> Ao ser lançada uma nova versão, é iniciado o processo de homologação >> do pacote no branch (1.0). Enquanto isso o desenvolvimento é >> continuado com novas implementações (trunk) para a futura versão 1.1. >> Ao ser detectado um problema em homologação (1.0 do branch), a >> correção deve ser feita pelo desenvolvedor, porém a versão do trunk já >> não é mais a mesma da que existe no branch.
>> Qual é a melhor forma de fazer a correção do problema encontrado na >> versão 1.0 do branch sem liberar as implementações feitas na versão >> 1.1 do trunk?
>> Se um desenvolvedor da equipe dar um revert para essa versão 1.0, >> fazer as correções e gravar no branch para novos testes já temos que >> também fazer a correção na versão que já está em desenvolvimento no >> trunk, dando trabalho dobrado (atualizar 2 arquivos).
>> O merge ajuda, mas nem tanto, pois acusará bastante diferença entre a >> versão corrigida (do branch) e a versão do trunk que continuou em >> desenvolvimento enquanto a versão 1.1 (do branch) era testada.
>> Alguma sugestão? Questionem caso a explicação não tenha ficado clara.
> Valeu Erick, mas existe alguma solução sem utilizar algum software > adicional? Ou então alguma opção open-source e principalmente para > linux?
> Esqueci de mencionar que nossos ambientes de desenvolvimento são linux.
> O problema maior é de fazer duas vezes a mesma alteração em arquivos > diferentes. Dependendo da quantidade de diferença entre ambas, o > processo de merge fica extremamente demorado e suscetível a erros.
> 2008/7/3 Erick Couto <erickcout...@gmail.com>: >> a melhor solução se chama StarTeam, da Borland. O suporte a diferentes >> releases permite um controle preciso do que deve e pode ser commitado em >> cada versão. Além de Integrar os CR (Change Request) diretamente com o >> controle de versão.
>> Em 03/07/08, William G. Comnisky <w.comni...@gmail.com> escreveu:
>>> Bom dia,
>>> Estamos com um problema talvez até conceitual sobre controle de versão >>> e gostaria de opiniões sobre a utilização em grandes projetos. Vamos >>> ao nosso cenário atual.
>>> Temos um repositório com 3 diretórios: >>> - trunk: atualizações diárias dos desenvolvedores >>> - branch: homologação/testes >>> - tag: versões de produção
>>> Ao ser lançada uma nova versão, é iniciado o processo de homologação >>> do pacote no branch (1.0). Enquanto isso o desenvolvimento é >>> continuado com novas implementações (trunk) para a futura versão 1.1. >>> Ao ser detectado um problema em homologação (1.0 do branch), a >>> correção deve ser feita pelo desenvolvedor, porém a versão do trunk já >>> não é mais a mesma da que existe no branch.
>>> Qual é a melhor forma de fazer a correção do problema encontrado na >>> versão 1.0 do branch sem liberar as implementações feitas na versão >>> 1.1 do trunk?
>>> Se um desenvolvedor da equipe dar um revert para essa versão 1.0, >>> fazer as correções e gravar no branch para novos testes já temos que >>> também fazer a correção na versão que já está em desenvolvimento no >>> trunk, dando trabalho dobrado (atualizar 2 arquivos).
>>> O merge ajuda, mas nem tanto, pois acusará bastante diferença entre a >>> versão corrigida (do branch) e a versão do trunk que continuou em >>> desenvolvimento enquanto a versão 1.1 (do branch) era testada.
>>> Alguma sugestão? Questionem caso a explicação não tenha ficado clara.
>>> obrigado, >>> William G. Comnisky
-- Abraço,
Felipe Cardoso Martins felipe.cardoso.mart...@gmail.com
> Valeu Erick, mas existe alguma solução sem utilizar algum software > adicional? Ou então alguma opção open-source e principalmente para > linux?
> Esqueci de mencionar que nossos ambientes de desenvolvimento são linux.
> O problema maior é de fazer duas vezes a mesma alteração em arquivos > diferentes. Dependendo da quantidade de diferença entre ambas, o > processo de merge fica extremamente demorado e suscetível a erros.
> 2008/7/3 Erick Couto <erickcout...@gmail.com>: > > a melhor solução se chama StarTeam, da Borland. O suporte a diferentes > > releases permite um controle preciso do que deve e pode ser commitado em > > cada versão. Além de Integrar os CR (Change Request) diretamente com o > > controle de versão.
> > Em 03/07/08, William G. Comnisky <w.comni...@gmail.com> escreveu:
> >> Bom dia,
> >> Estamos com um problema talvez até conceitual sobre controle de versão > >> e gostaria de opiniões sobre a utilização em grandes projetos. Vamos > >> ao nosso cenário atual.
> >> Temos um repositório com 3 diretórios: > >> - trunk: atualizações diárias dos desenvolvedores > >> - branch: homologação/testes > >> - tag: versões de produção
> >> Ao ser lançada uma nova versão, é iniciado o processo de homologação > >> do pacote no branch (1.0). Enquanto isso o desenvolvimento é > >> continuado com novas implementações (trunk) para a futura versão 1.1. > >> Ao ser detectado um problema em homologação (1.0 do branch), a > >> correção deve ser feita pelo desenvolvedor, porém a versão do trunk já > >> não é mais a mesma da que existe no branch.
> >> Qual é a melhor forma de fazer a correção do problema encontrado na > >> versão 1.0 do branch sem liberar as implementações feitas na versão > >> 1.1 do trunk?
> >> Se um desenvolvedor da equipe dar um revert para essa versão 1.0, > >> fazer as correções e gravar no branch para novos testes já temos que > >> também fazer a correção na versão que já está em desenvolvimento no > >> trunk, dando trabalho dobrado (atualizar 2 arquivos).
> >> O merge ajuda, mas nem tanto, pois acusará bastante diferença entre a > >> versão corrigida (do branch) e a versão do trunk que continuou em > >> desenvolvimento enquanto a versão 1.1 (do branch) era testada.
> >> Alguma sugestão? Questionem caso a explicação não tenha ficado clara.
> Se não me engano ele vai gerar um conflito que deverá ser resolvido > manualmente... Estou enganado?
> 2008/7/3 William G. Comnisky <w.comni...@gmail.com>: >> Valeu Erick, mas existe alguma solução sem utilizar algum software >> adicional? Ou então alguma opção open-source e principalmente para >> linux?
>> Esqueci de mencionar que nossos ambientes de desenvolvimento são linux.
>> O problema maior é de fazer duas vezes a mesma alteração em arquivos >> diferentes. Dependendo da quantidade de diferença entre ambas, o >> processo de merge fica extremamente demorado e suscetível a erros.
>> 2008/7/3 Erick Couto <erickcout...@gmail.com>: >>> a melhor solução se chama StarTeam, da Borland. O suporte a diferentes >>> releases permite um controle preciso do que deve e pode ser commitado em >>> cada versão. Além de Integrar os CR (Change Request) diretamente com o >>> controle de versão.
>>> Em 03/07/08, William G. Comnisky <w.comni...@gmail.com> escreveu:
>>>> Bom dia,
>>>> Estamos com um problema talvez até conceitual sobre controle de versão >>>> e gostaria de opiniões sobre a utilização em grandes projetos. Vamos >>>> ao nosso cenário atual.
>>>> Temos um repositório com 3 diretórios: >>>> - trunk: atualizações diárias dos desenvolvedores >>>> - branch: homologação/testes >>>> - tag: versões de produção
>>>> Ao ser lançada uma nova versão, é iniciado o processo de homologação >>>> do pacote no branch (1.0). Enquanto isso o desenvolvimento é >>>> continuado com novas implementações (trunk) para a futura versão 1.1. >>>> Ao ser detectado um problema em homologação (1.0 do branch), a >>>> correção deve ser feita pelo desenvolvedor, porém a versão do trunk já >>>> não é mais a mesma da que existe no branch.
>>>> Qual é a melhor forma de fazer a correção do problema encontrado na >>>> versão 1.0 do branch sem liberar as implementações feitas na versão >>>> 1.1 do trunk?
>>>> Se um desenvolvedor da equipe dar um revert para essa versão 1.0, >>>> fazer as correções e gravar no branch para novos testes já temos que >>>> também fazer a correção na versão que já está em desenvolvimento no >>>> trunk, dando trabalho dobrado (atualizar 2 arquivos).
>>>> O merge ajuda, mas nem tanto, pois acusará bastante diferença entre a >>>> versão corrigida (do branch) e a versão do trunk que continuou em >>>> desenvolvimento enquanto a versão 1.1 (do branch) era testada.
>>>> Alguma sugestão? Questionem caso a explicação não tenha ficado clara.
>>>> obrigado, >>>> William G. Comnisky
> -- > Abraço,
> Felipe Cardoso Martins > felipe.cardoso.mart...@gmail.com
> 2008/7/3 Felipe Cardoso Martins <felipe.cardoso.mart...@gmail.com>:
> > Se não me engano ele vai gerar um conflito que deverá ser resolvido > > manualmente... Estou enganado?
> > 2008/7/3 William G. Comnisky <w.comni...@gmail.com>: > >> Valeu Erick, mas existe alguma solução sem utilizar algum software > >> adicional? Ou então alguma opção open-source e principalmente para > >> linux?
> >> Esqueci de mencionar que nossos ambientes de desenvolvimento são linux.
> >> O problema maior é de fazer duas vezes a mesma alteração em arquivos > >> diferentes. Dependendo da quantidade de diferença entre ambas, o > >> processo de merge fica extremamente demorado e suscetível a erros.
> >> 2008/7/3 Erick Couto <erickcout...@gmail.com>: > >>> a melhor solução se chama StarTeam, da Borland. O suporte a diferentes > >>> releases permite um controle preciso do que deve e pode ser commitado > em > >>> cada versão. Além de Integrar os CR (Change Request) diretamente com o > >>> controle de versão.
> >>> Em 03/07/08, William G. Comnisky <w.comni...@gmail.com> escreveu:
> >>>> Bom dia,
> >>>> Estamos com um problema talvez até conceitual sobre controle de versão > >>>> e gostaria de opiniões sobre a utilização em grandes projetos. Vamos > >>>> ao nosso cenário atual.
> >>>> Temos um repositório com 3 diretórios: > >>>> - trunk: atualizações diárias dos desenvolvedores > >>>> - branch: homologação/testes > >>>> - tag: versões de produção
> >>>> Ao ser lançada uma nova versão, é iniciado o processo de homologação > >>>> do pacote no branch (1.0). Enquanto isso o desenvolvimento é > >>>> continuado com novas implementações (trunk) para a futura versão 1.1. > >>>> Ao ser detectado um problema em homologação (1.0 do branch), a > >>>> correção deve ser feita pelo desenvolvedor, porém a versão do trunk já > >>>> não é mais a mesma da que existe no branch.
> >>>> Qual é a melhor forma de fazer a correção do problema encontrado na > >>>> versão 1.0 do branch sem liberar as implementações feitas na versão > >>>> 1.1 do trunk?
> >>>> Se um desenvolvedor da equipe dar um revert para essa versão 1.0, > >>>> fazer as correções e gravar no branch para novos testes já temos que > >>>> também fazer a correção na versão que já está em desenvolvimento no > >>>> trunk, dando trabalho dobrado (atualizar 2 arquivos).
> >>>> O merge ajuda, mas nem tanto, pois acusará bastante diferença entre a > >>>> versão corrigida (do branch) e a versão do trunk que continuou em > >>>> desenvolvimento enquanto a versão 1.1 (do branch) era testada.
> >>>> Alguma sugestão? Questionem caso a explicação não tenha ficado clara.
> >>>> obrigado, > >>>> William G. Comnisky
> > -- > > Abraço,
> > Felipe Cardoso Martins > > felipe.cardoso.mart...@gmail.com
att. Bruno Gross Analista de Sistemas Celular: (21) 78545483 ID 83*39379 Skype: brugross
Esta mensagem, incluindo seus anexos, pode conter informações confidenciais e/ou privilegiadas. Se você não for a pessoa autorizada a receber esta mensagem, não pode usar, copiar ou divulgar as informações nela contidas ou tomar qualquer ação baseada nessas informações. Caso esta mensagem tenha sido recebida por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida elimine-a do seu sistema. Agradeço sua cooperação.
> 2008/7/3 William G. Comnisky <w.comni...@gmail.com>:
>> Correto.
>> 2008/7/3 Felipe Cardoso Martins <felipe.cardoso.mart...@gmail.com>:
>> > Se não me engano ele vai gerar um conflito que deverá ser resolvido >> > manualmente... Estou enganado?
>> > 2008/7/3 William G. Comnisky <w.comni...@gmail.com>: >> >> Valeu Erick, mas existe alguma solução sem utilizar algum software >> >> adicional? Ou então alguma opção open-source e principalmente para >> >> linux?
>> >> Esqueci de mencionar que nossos ambientes de desenvolvimento são linux.
>> >> O problema maior é de fazer duas vezes a mesma alteração em arquivos >> >> diferentes. Dependendo da quantidade de diferença entre ambas, o >> >> processo de merge fica extremamente demorado e suscetível a erros.
>> >> 2008/7/3 Erick Couto <erickcout...@gmail.com>: >> >>> a melhor solução se chama StarTeam, da Borland. O suporte a diferentes >> >>> releases permite um controle preciso do que deve e pode ser commitado >> >>> em >> >>> cada versão. Além de Integrar os CR (Change Request) diretamente com o >> >>> controle de versão.
>> >>> Em 03/07/08, William G. Comnisky <w.comni...@gmail.com> escreveu:
>> >>>> Bom dia,
>> >>>> Estamos com um problema talvez até conceitual sobre controle de >> >>>> versão >> >>>> e gostaria de opiniões sobre a utilização em grandes projetos. Vamos >> >>>> ao nosso cenário atual.
>> >>>> Temos um repositório com 3 diretórios: >> >>>> - trunk: atualizações diárias dos desenvolvedores >> >>>> - branch: homologação/testes >> >>>> - tag: versões de produção
>> >>>> Ao ser lançada uma nova versão, é iniciado o processo de homologação >> >>>> do pacote no branch (1.0). Enquanto isso o desenvolvimento é >> >>>> continuado com novas implementações (trunk) para a futura versão 1.1. >> >>>> Ao ser detectado um problema em homologação (1.0 do branch), a >> >>>> correção deve ser feita pelo desenvolvedor, porém a versão do trunk >> >>>> já >> >>>> não é mais a mesma da que existe no branch.
>> >>>> Qual é a melhor forma de fazer a correção do problema encontrado na >> >>>> versão 1.0 do branch sem liberar as implementações feitas na versão >> >>>> 1.1 do trunk?
>> >>>> Se um desenvolvedor da equipe dar um revert para essa versão 1.0, >> >>>> fazer as correções e gravar no branch para novos testes já temos que >> >>>> também fazer a correção na versão que já está em desenvolvimento no >> >>>> trunk, dando trabalho dobrado (atualizar 2 arquivos).
>> >>>> O merge ajuda, mas nem tanto, pois acusará bastante diferença entre a >> >>>> versão corrigida (do branch) e a versão do trunk que continuou em >> >>>> desenvolvimento enquanto a versão 1.1 (do branch) era testada.
>> >>>> Alguma sugestão? Questionem caso a explicação não tenha ficado clara.
>> >>>> obrigado, >> >>>> William G. Comnisky
>> > -- >> > Abraço,
>> > Felipe Cardoso Martins >> > felipe.cardoso.mart...@gmail.com
> att. > Bruno Gross > Analista de Sistemas > Celular: (21) 78545483 ID 83*39379 > Skype: brugross
> Esta mensagem, incluindo seus anexos, pode conter informações confidenciais > e/ou privilegiadas. Se você não for a pessoa autorizada a receber esta > mensagem, não pode usar, copiar ou divulgar as informações nela contidas ou > tomar qualquer ação baseada nessas informações. Caso esta mensagem tenha > sido recebida por engano, por favor avise imediatamente o remetente, > respondendo o e-mail e em seguida elimine-a do seu sistema. Agradeço sua > cooperação.
> Preferencialmente, pois a empresa optou por essa linha, e dificilmente > entrará no software proprietário.
> 2008/7/3 Bruno Gross <brunogr...@gmail.com>: > > tem q ser software Unix?
> > 2008/7/3 William G. Comnisky <w.comni...@gmail.com>:
> >> Correto.
> >> 2008/7/3 Felipe Cardoso Martins <felipe.cardoso.mart...@gmail.com>:
> >> > Se não me engano ele vai gerar um conflito que deverá ser resolvido > >> > manualmente... Estou enganado?
> >> > 2008/7/3 William G. Comnisky <w.comni...@gmail.com>: > >> >> Valeu Erick, mas existe alguma solução sem utilizar algum software > >> >> adicional? Ou então alguma opção open-source e principalmente para > >> >> linux?
> >> >> Esqueci de mencionar que nossos ambientes de desenvolvimento são > linux.
> >> >> O problema maior é de fazer duas vezes a mesma alteração em arquivos > >> >> diferentes. Dependendo da quantidade de diferença entre ambas, o > >> >> processo de merge fica extremamente demorado e suscetível a erros.
> >> >> 2008/7/3 Erick Couto <erickcout...@gmail.com>: > >> >>> a melhor solução se chama StarTeam, da Borland. O suporte a > diferentes > >> >>> releases permite um controle preciso do que deve e pode ser > commitado > >> >>> em > >> >>> cada versão. Além de Integrar os CR (Change Request) diretamente com > o > >> >>> controle de versão.
> >> >>> Em 03/07/08, William G. Comnisky <w.comni...@gmail.com> escreveu:
> >> >>>> Bom dia,
> >> >>>> Estamos com um problema talvez até conceitual sobre controle de > >> >>>> versão > >> >>>> e gostaria de opiniões sobre a utilização em grandes projetos. > Vamos > >> >>>> ao nosso cenário atual.
> >> >>>> Temos um repositório com 3 diretórios: > >> >>>> - trunk: atualizações diárias dos desenvolvedores > >> >>>> - branch: homologação/testes > >> >>>> - tag: versões de produção
> >> >>>> Ao ser lançada uma nova versão, é iniciado o processo de > homologação > >> >>>> do pacote no branch (1.0). Enquanto isso o desenvolvimento é > >> >>>> continuado com novas implementações (trunk) para a futura versão > 1.1. > >> >>>> Ao ser detectado um problema em homologação (1.0 do branch), a > >> >>>> correção deve ser feita pelo desenvolvedor, porém a versão do trunk > >> >>>> já > >> >>>> não é mais a mesma da que existe no branch.
> >> >>>> Qual é a melhor forma de fazer a correção do problema encontrado na > >> >>>> versão 1.0 do branch sem liberar as implementações feitas na versão > >> >>>> 1.1 do trunk?
> >> >>>> Se um desenvolvedor da equipe dar um revert para essa versão 1.0, > >> >>>> fazer as correções e gravar no branch para novos testes já temos > que > >> >>>> também fazer a correção na versão que já está em desenvolvimento no > >> >>>> trunk, dando trabalho dobrado (atualizar 2 arquivos).
> >> >>>> O merge ajuda, mas nem tanto, pois acusará bastante diferença entre > a > >> >>>> versão corrigida (do branch) e a versão do trunk que continuou em > >> >>>> desenvolvimento enquanto a versão 1.1 (do branch) era testada.
> >> >>>> Alguma sugestão? Questionem caso a explicação não tenha ficado > clara.
> >> >>>> obrigado, > >> >>>> William G. Comnisky
> >> > -- > >> > Abraço,
> >> > Felipe Cardoso Martins > >> > felipe.cardoso.mart...@gmail.com
> > att. > > Bruno Gross > > Analista de Sistemas > > Celular: (21) 78545483 ID 83*39379 > > Skype: brugross
> > Esta mensagem, incluindo seus anexos, pode conter informações > confidenciais > > e/ou privilegiadas. Se você não for a pessoa autorizada a receber esta > > mensagem, não pode usar, copiar ou divulgar as informações nela contidas > ou > > tomar qualquer ação baseada nessas informações. Caso esta mensagem tenha > > sido recebida por engano, por favor avise imediatamente o remetente, > > respondendo o e-mail e em seguida elimine-a do seu sistema. Agradeço sua > > cooperação.
att. Bruno Gross Analista de Sistemas Celular: (21) 78545483 ID 83*39379 Skype: brugross
Esta mensagem, incluindo seus anexos, pode conter informações confidenciais e/ou privilegiadas. Se você não for a pessoa autorizada a receber esta mensagem, não pode usar, copiar ou divulgar as informações nela contidas ou tomar qualquer ação baseada nessas informações. Caso esta mensagem tenha sido recebida por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida elimine-a do seu sistema. Agradeço sua cooperação.
