You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Leonardo Laface de Almeida <le...@sweda.com.br> on 2012/08/14 14:14:47 UTC
Libraries and projects into SVN
Hello.
We desire to insert some projects into SVN and we have now to deal with some
witch uses the same library. The developers here said that we always
actualize the last library in order to be compatible with the older ones.
We have talked about it and we think we have to create an individual
repository for the library and the developers should actualize it very often
manually. I mean, every time someone wants to change some project, he must
to check out the project version and the libraries versions required for it.
After developing or correction, the developer must actualize the project and
the libraries separated.
My questions are:
1) Is that right? I mean, Is there any better other way to control
versions of libraries used for several projects?
2) Is it possible in SVN to make it automatic ? In other words, when
the developer actualize (commit, merge, etc...) some project, is it possible
to actualize the libraries together? One of us said it's possible to do this
in GIT using sub-repositories. Is it possible in SVN? If so, is there any
tutorial or advices to do this?
I'm already glad for answers.
Regards,
Leonardo
Re: Libraries and projects into SVN
Posted by pe...@stuba.sk.
On Tuesday, August 14, 2012 09:14:47 Leonardo Laface de Almeida wrote:
We have talked about it and we think we have to create an individual
repository for the library and the developers should actualize it very often
manually. I mean, every time someone wants to change some project, he must to
check out the project version and the libraries versions required for it.
After developing or correction, the developer must actualize the project and
the libraries separated.
My questions are:
1) Is that right? I mean, Is there any better other way to control
versions of libraries used for several projects?
I think use of svn:extrenals is the best soluition for this. Svn: extrenals
connects repostiory or its part as an directory inside project. When someone
changes file inside this directory and commit, canges in taht directory are
commited into that shared repository or directory
Peter
Re: Libraries and projects into SVN
Posted by Les Mikesell <le...@gmail.com>.
On Tue, Aug 14, 2012 at 9:05 AM, Leonardo Laface de Almeida
<le...@sweda.com.br> wrote:
>
> So, three main situations:
>
> 1) When source code from P1 changes module M1, the P2 must have access to
> it, and vice-versa.
> 2) When source code from P1 changes shared code from L1, the L1 source code
> must be actualized, and vice-versa.
> 3) When L1.dll changes, A1, A2 and A3 should automatically start to use the
> new L1 created.
>
>
> I'm still a bit lost here how to share the codes into SVN. I think I may
> create one repository to each one (P1, P2, M1, L1, A1, A2 and A3). The
> problem is doing all svn commands for each one.
>
> For example, If I will change L1, I must to check out P1 and M1 to compile
> it. Then, after changes, I must commit P1, M1 and L1, for source code and
> commit the L1.dll file for A1, A2 and A3. It's unlikelly doing this
> manually.
>
> In other hand, I also think it's unlikelly to create only one repository for
> all these projects.
It doesn't really matter whether each project has its own repository
or not, as long as the shared components each have their own top-level
subdirectory. For each shared thing needed for a build, just use an
svn external reference in the project that needs it to pull it into a
subdirectory of the workspace. If you want to use pre-built .dlls,
you can commit them back as well. For ongoing development you might
let the externals reference the trunk versions of the components, but
you will probably want to establish a naming convention for your
branches and tags from the start. As you approach release versions
of each projects you would normally want to tie the externals to
tagged versions of each component in case the component development
continues in incompatible/untested ways on the trunk.
--
Les Mikesell
lesmikesell@gmail.com
AW: Libraries and projects into SVN
Posted by Markus Schaber <m....@3s-software.com>.
Hi,
Von: Leonardo Laface de Almeida [mailto:leonardo@sweda.com.br]
>
> The system here is a bit complex and I will try to explain it.
>
> We have two main projects (P1 and P2). They are compiled in separated
> environments, generating *.exe different files, but they use the same
> source code allocated into a module (M1), that contains some
> functionalities like file system, file transfer, etc.
>
> We have also one library (L1) with 80% of source code equivalent of P1,
> and it is compiled separated from P1, generating a L1.dll file.
>
> The library L1 is used by three other application projects (A1, A2 and
> A3).
This looks like a classical use case for SVN externals. Put the common
code into its own project which is referenced via svn:externals into a
subdirectory of P1, P2 and L1.
> So, three main situations:
>
> 1) When source code from P1 changes module M1, the P2 must have access to
> it, and vice-versa.
> 2) When source code from P1 changes shared code from L1, the L1 source
> code
> must be actualized, and vice-versa.
> 3) When L1.dll changes, A1, A2 and A3 should automatically start to use
> the new L1 created.
>
> I'm still a bit lost here how to share the codes into SVN. I think I may
> create one repository to each one (P1, P2, M1, L1, A1, A2 and A3). The
> problem is doing all svn commands for each one.
>
> For example, If I will change L1, I must to check out P1 and M1 to compile
> it. Then, after changes, I must commit P1, M1 and L1, for source code and
> commit the L1.dll file for A1, A2 and A3. It's unlikelly doing this
> manually.
Svn externals or your build scripts, or even better a continuous integration
Tool can be used to take care of that.
> In other hand, I also think it's unlikelly to create only one repository
> for all these projects.
Why is that unlikely?
The Apache Software Foundation hosts nearly all of their 100+ projects
together in one big Subversion repository.
Each project has its subdirectory, and its own trunk/branches/tags structure
therein. It works fine.
> Finally, our system is a bit more complex than it, but the main structure
> is this.
HTH,
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
RES: Libraries and projects into SVN
Posted by Leonardo Laface de Almeida <le...@sweda.com.br>.
Hi,
The system here is a bit complex and I will try to explain it.
We have two main projects (P1 and P2). They are compiled in separated
environments, generating *.exe different files, but they use the same source
code allocated into a module (M1), that contains some functionalities like
file system, file transfer, etc.
We have also one library (L1) with 80% of source code equivalent of P1, and
it is compiled separated from P1, generating a L1.dll file.
The library L1 is used by three other application projects (A1, A2 and A3).
So, three main situations:
1) When source code from P1 changes module M1, the P2 must have access to
it, and vice-versa.
2) When source code from P1 changes shared code from L1, the L1 source code
must be actualized, and vice-versa.
3) When L1.dll changes, A1, A2 and A3 should automatically start to use the
new L1 created.
I'm still a bit lost here how to share the codes into SVN. I think I may
create one repository to each one (P1, P2, M1, L1, A1, A2 and A3). The
problem is doing all svn commands for each one.
For example, If I will change L1, I must to check out P1 and M1 to compile
it. Then, after changes, I must commit P1, M1 and L1, for source code and
commit the L1.dll file for A1, A2 and A3. It's unlikelly doing this
manually.
In other hand, I also think it's unlikelly to create only one repository for
all these projects.
Finally, our system is a bit more complex than it, but the main structure is
this.
Thanks again for your suggestions.
Regards
Leonardo
-----Mensagem original-----
De: Ulrich Eckhardt [mailto:ulrich.eckhardt@dominolaser.com]
Enviada em: terça-feira, 14 de agosto de 2012 09:43
Para: users@subversion.apache.org
Assunto: Re: Libraries and projects into SVN
Am 14.08.2012 14:14, schrieb Leonardo Laface de Almeida:
> We desire to insert some projects into SVN and we have now to deal with
some
> witch uses the same library. The developers here said that we always
> actualize the last library in order to be compatible with the older ones.
Okay, so there is a component (a library) that is shared between
different projects, right? Or is it that you check in the compiled .DLLs
or .LIBs separately to the source code?
This question is very important because of the different implications
and strategies for approaching it. Reading the rest of your mail also
doesn't make it clear, so it is impossible to give you proper advise
without you answering that part first.
Note that what Peter suggested mostly deals with how to share the
content between different projects using it and not so much with how to
store it. In any case, svn:externals are a good tool but they are not
always the right one.
Greetings!
Uli
****************************************************************************
**********
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
****************************************************************************
**********
Visit our website at http://www.dominolaser.com
****************************************************************************
**********
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten
bestimmt und kann vertrauliche Informationen enthalten. Bitte
benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte
Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf
weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt
werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht
verantwortlich.
****************************************************************************
**********
Re: Libraries and projects into SVN
Posted by Ulrich Eckhardt <ul...@dominolaser.com>.
Am 14.08.2012 14:14, schrieb Leonardo Laface de Almeida:
> We desire to insert some projects into SVN and we have now to deal with some
> witch uses the same library. The developers here said that we always
> actualize the last library in order to be compatible with the older ones.
Okay, so there is a component (a library) that is shared between
different projects, right? Or is it that you check in the compiled .DLLs
or .LIBs separately to the source code?
This question is very important because of the different implications
and strategies for approaching it. Reading the rest of your mail also
doesn't make it clear, so it is impossible to give you proper advise
without you answering that part first.
Note that what Peter suggested mostly deals with how to share the
content between different projects using it and not so much with how to
store it. In any case, svn:externals are a good tool but they are not
always the right one.
Greetings!
Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************