You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Shapira, Yoav" <Yo...@mpi.com> on 2004/08/06 16:50:36 UTC
[OFF-TOPIC] RE: Source Control Ideas.
Hola, (or perhaps, Kalimera?)
>Since this is a nice active list of plenty of developers and I have no
>other idea where I can post theses questions...
>
>My questions are concerning source control in general
We ask that you prepend [OFF-TOPIC] to the subject line of messages not
related to Tomcat. I'll also point you at some other resources for your
future reference:
http://www.jguru.com/forums/index.jsp
http://forum.java.sun.com/
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=comp.lang.java
>1- Is there any good books, articles, web sites tutorials...
Yes, there are plenty: Google is your friend.
>Now all of a sudden I realise that product2 can also use p1web1 which
in
>turn uses p1db2. So now I have to make slight changes to p1web1 and
>p1db2 to support product 2.
>Now both products share p1web1 and p1db2. Lets say a bug is found on
>p1web1. Analysis is done and the bug only affects product1...
>
>How could source control be managed, structured when multiple products
>may share mutltiple "components"
The general approach is to set up a separate "component" in source
control for each component of your code that can be depended upon. All
modern source control systems allow you to label branches, so you can
have a DB1_1.0 label for database 1 code version 1.0. Product 1 can
depend on this. Then as you make further changes you label is DB1_1.1
or maybe DB1_2.0 as you wish, and you change dependencies accordingly.
Product 1 can still depend on 1.0 if it wishes, and you can still make
changes in the 1.0 branch.
As to your other question, all modern source control systems allow you
set views and work with branches, and then merge them if/when you see
fit. These are fairly basic source control questions, so maybe you
should check out a book or article like
http://www-106.ibm.com/developerworks/rational/library/2110.html
http://cvsbook.red-bean.com/
http://www.utexas.edu/cc/unix/UsingSCCS.html
http://www.developer.com/mgmt/article.php/3330801
or a class like
http://www.inferdata.com/training/websphere/ClearCase.html
As I said, Google is your friend -- this information is not hard to
find.
Yoav
This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: [OFF-TOPIC] RE: Source Control Ideas.
Posted by Anastasios Angelidis <vo...@videotron.ca>.
Robert Bateman wrote:
>On Friday 06 August 2004 11:36 am, Anastasios Angelidis wrote:
>
>
>>>The general approach is to set up a separate "component" in source
>>>control for each component of your code that can be depended upon. All
>>>modern source control systems allow you to label branches, so you can
>>>have a DB1_1.0 label for database 1 code version 1.0. Product 1 can
>>>depend on this. Then as you make further changes you label is DB1_1.1
>>>or maybe DB1_2.0 as you wish, and you change dependencies accordingly.
>>>Product 1 can still depend on 1.0 if it wishes, and you can still make
>>>changes in the 1.0 branch.
>>>
>>>
>>But what happens, when both products depend/share functionality on this
>>component simultanously.
>>
>>
>
>Don't forget how java "shares" code: jar files
>
>If you build your shared functionality into a jar, you can deploy that jar in
>support of that functionality. Building different versions of a particular
>shared code base is simply a matter of extracting a particular branch of
>source and performing the build.
>
>Bob
>
>
>
Thats cool, though am more intersted in general. Most of our stuff is MS
SQL and C++ related, java is used less.
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: [OFF-TOPIC] RE: Source Control Ideas.
Posted by Robert Bateman <bo...@sequoiallc.com>.
On Friday 06 August 2004 11:36 am, Anastasios Angelidis wrote:
> >The general approach is to set up a separate "component" in source
> >control for each component of your code that can be depended upon. All
> >modern source control systems allow you to label branches, so you can
> >have a DB1_1.0 label for database 1 code version 1.0. Product 1 can
> >depend on this. Then as you make further changes you label is DB1_1.1
> >or maybe DB1_2.0 as you wish, and you change dependencies accordingly.
> >Product 1 can still depend on 1.0 if it wishes, and you can still make
> >changes in the 1.0 branch.
>
> But what happens, when both products depend/share functionality on this
> component simultanously.
Don't forget how java "shares" code: jar files
If you build your shared functionality into a jar, you can deploy that jar in
support of that functionality. Building different versions of a particular
shared code base is simply a matter of extracting a particular branch of
source and performing the build.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: [OFF-TOPIC] RE: Source Control Ideas.
Posted by Anastasios Angelidis <vo...@videotron.ca>.
Shapira, Yoav wrote:
>Hola, (or perhaps, Kalimera?)
>
>
>
>>Since this is a nice active list of plenty of developers and I have no
>>other idea where I can post theses questions...
>>
>>My questions are concerning source control in general
>>
>>
>
>We ask that you prepend [OFF-TOPIC] to the subject line of messages not
>related to Tomcat. I'll also point you at some other resources for your
>future reference:
>http://www.jguru.com/forums/index.jsp
>http://forum.java.sun.com/
>http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=comp.lang.java
>
>
>
>>1- Is there any good books, articles, web sites tutorials...
>>
>>
>
>Yes, there are plenty: Google is your friend.
>
>
>
>>Now all of a sudden I realise that product2 can also use p1web1 which
>>
>>
>in
>
>
>>turn uses p1db2. So now I have to make slight changes to p1web1 and
>>p1db2 to support product 2.
>>Now both products share p1web1 and p1db2. Lets say a bug is found on
>>p1web1. Analysis is done and the bug only affects product1...
>>
>>How could source control be managed, structured when multiple products
>>may share mutltiple "components"
>>
>>
>
>The general approach is to set up a separate "component" in source
>control for each component of your code that can be depended upon. All
>modern source control systems allow you to label branches, so you can
>have a DB1_1.0 label for database 1 code version 1.0. Product 1 can
>depend on this. Then as you make further changes you label is DB1_1.1
>or maybe DB1_2.0 as you wish, and you change dependencies accordingly.
>Product 1 can still depend on 1.0 if it wishes, and you can still make
>changes in the 1.0 branch.
>
>
But what happens, when both products depend/share functionality on this
component simultanously.
>As to your other question, all modern source control systems allow you
>set views and work with branches, and then merge them if/when you see
>fit. These are fairly basic source control questions, so maybe you
>should check out a book or article like
>http://www-106.ibm.com/developerworks/rational/library/2110.html
>http://cvsbook.red-bean.com/
>http://www.utexas.edu/cc/unix/UsingSCCS.html
>http://www.developer.com/mgmt/article.php/3330801
>or a class like
>http://www.inferdata.com/training/websphere/ClearCase.html
>
>
>As I said, Google is your friend -- this information is not hard to
>find.
>
>Yoav
>
>
>
>
>
>This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org