You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Anastasios Angelidis <vo...@videotron.ca> on 2005/11/03 18:21:16 UTC
General - Version questions?
This is some questions in general I'm hoping some of you can answer...
Where I come from we do all versioning by hand and have come acustomed
to certain procedures that we have implemented. I'm currently looking at
implementing subversion for our version control and would like to see
how I can integrate svn with out processes to possibly remove some of
the manual work.
1- We have the following structure: Builds -> Projects -> Components ->
Elements
Build: Contains multiple projects
Project: Contains multiple components (Executables, Dbs, Web etc...)
Component: Contains multiple elements (source files etc...)
We have a custom in house to that we track versions like 4.3.5 in a sql DB.
1- Would I be able to track version numbers through svn, without having
to rely on the sql db?
2- What would be the best way to handle a "build" as described above. As
using 3 levels in a directory treet structure is cumbersome.
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: General - Version questions?
Posted by Paul Koning <pk...@equallogic.com>.
>>>>> "Anastasios" == Anastasios Angelidis <vo...@videotron.ca> writes:
Anastasios> 1- We have the following structure: Builds -> Projects ->
Anastasios> Components -> Elements
Anastasios> Build: Contains multiple projects Project: Contains
Anastasios> multiple components (Executables, Dbs, Web etc...)
Anastasios> Component: Contains multiple elements (source files
Anastasios> etc...)
Anastasios> We have a custom in house to that we track versions like
Anastasios> 4.3.5 in a sql DB.
Anastasios> 1- Would I be able to track version numbers through svn,
Anastasios> without having to rely on the sql db?
Sure. One simple approach I have used is to create a file (perhaps
"version.h") which contains the version string. Then just apply SVN
revision control to that file.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: General - Version questions?
Posted by Anastasios Angelidis <vo...@videotron.ca>.
William Nagel wrote:
> On Nov 3, 2005, at 2:51 PM, Anastasios Angelidis wrote:
>
>> Duncan Murdoch wrote:
>>
>>
>>> On 11/3/2005 1:52 PM, Anastasios Angelidis wrote:
>>>
>>>
>>>> Duncan Murdoch wrote:
>>>>
>>>>
>>>>> On 11/3/2005 1:21 PM, Anastasios Angelidis wrote:
>>>>>
>>>>>
>>>>>> This is some questions in general I'm hoping some of you can
>>>>>> answer...
>>>>>>
>>>>>> Where I come from we do all versioning by hand and have come
>>>>>> acustomed to certain procedures that we have implemented. I'm
>>>>>> currently looking at implementing subversion for our version
>>>>>> control and would like to see how I can integrate svn with out
>>>>>> processes to possibly remove some of the manual work.
>>>>>>
>>>>>> 1- We have the following structure: Builds -> Projects ->
>>>>>> Components -> Elements
>>>>>>
>>>>>> Build: Contains multiple projects
>>>>>> Project: Contains multiple components (Executables, Dbs, Web
>>>>>> etc...)
>>>>>> Component: Contains multiple elements (source files etc...)
>>>>>>
>>>>>> We have a custom in house to that we track versions like 4.3.5
>>>>>> in a sql DB.
>>>>>>
>>>>>> 1- Would I be able to track version numbers through svn, without
>>>>>> having to rely on the sql db?
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Yes, it's very easy to record the version of every file in a
>>>>> collection by making a copy of the collection to a tag
>>>>> directory. (You don't actually make any physical copy, just a
>>>>> logical copy.)
>>>>>
>>>>>
>>>>>> 2- What would be the best way to handle a "build" as described
>>>>>> above. As using 3 levels in a directory treet structure is
>>>>>> cumbersome.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> There'd be no need to change your current directory structure.
>>>>> Just import it into subversion and call it the trunk.
>>>>>
>>>>
>>>>
>>>> The problem with what we call a "build" is that it canot be
>>>> represented well in a folder treet structure. Example I have a
>>>> build called Apple_Carot_Cake...
>>>>
>>>> The Apple_Carot_Cake build hosts an Apple project and a Carot
>>>> project.
>>>>
>>>> Then one day I decide to get fancy and create an Apple_Banana_Cake
>>>> (Nasty tasting lol). This build would require the Apple project
>>>> and a new Banana project.
>>>>
>>>> So now imagine that I would have to copy the Apple project to
>>>> another trunk and have now to maintaine separate Apple projects.
>>>> So when I need to update the Apple project I would then have to
>>>> remember to merge to the Apple_Carot_Cake and the
>>>> Apple_Banana_Cake apple trunks.
>>>>
>>>> Now that where versioning with the DB it's fairly easy to attach a
>>>> "build" identifier to a project. But this still doesn't translate
>>>> well to a tree folder structure like file explorer or svn. I'm
>>>> thinking of "build" beeing parallel to projects. Can I assign a
>>>> custom property called build to a project folder within subversion?
>>>>
>>>
>>>
>>> That sounds like what Subversion calls "Externals"; see http://
>>> svnbook.red-bean.com/en/1.1/ch07s04.html. I've never used them
>>> myself, so if you have any hard questions someone else will have to
>>> help with them.
>>>
>>
>> Humm I'm thinking more properties then externals. Cause even if I
>> set externals. I will always have to rember to switch to the proper
>> "aaple" project and still have to maintain 2 separate versions.
>
>
> Not if you use externals properly.
>
> If you have a layout like this:
>
> MySVNRepo
> --Apple
> --Trunk
> --Component 1
> --Component 2
> --etc
> --Branches
> --Tags
> --Carrot
> ...
> --Cake
> --Banana
> --Builds
> --Apple_Carrot_Cake
> -- svn:externals:
> Apple -r50 http://svn.yourserver.com/MySVNRepo/Apple/Trunk
> Carrot -r23 http://svn.yourserver.com/MySVNRepo/Carrot/Trunk
> Cake -r34 http://svn.yourserver.com/MySVNRepo/Cake/Trunk
> --Apple_Cake_Banana
> -- svn:externals:
> Apple -r92 http://svn.yourserver.com/MySVNRepo/Apple/Trunk
> Banana -r103 http://svn.yourserver.com/MySVNRepo/Banana/Trunk
> Cake -r243 http://svn.yourserver.com/MySVNRepo/Cake/Trunk
>
> Then, anyone who checks out Apple_Cake_Banana will get the
> Apple_Cake_Banana build will get Apple, Banana, and Cake at the
> appropriate revisions. Also, since svn:externals is just a property
> and properties are versioned, you can update a build to different
> versions of each project by just changing the svn:externals property.
>
Perfect this means when I branch my projects and tag them as well I can
also have the "builds" branched and have their externals point to the
branched projects. If so! Problem solved!
Thanks
>>
>> This is what I'm thinking of doing...
>>
>> MySVNRepo
>> |
>> |
>> |------ Apple <--- Attach a property "build" Build: Is used in
>> the Apple_Carot_Cake.
>> | |
>> | |
>> | |---- Branches
>> | |
>> | |---- Tags
>> | |
>> | |---- Trunk
>> | |
>> | |--- Component1
>> | |--- Component2
>> | |--- etc...
>> |
>> |
>> |------ Carot <--- Attach a property "build" Build: Is used in
>> the Apple_Carot_Cake.
>> | |
>> | ...
>>
>> So now when ever I move a project in a release branch I can adjust
>> the build property. And if not mistaken properties are versioned as
>> well.
>
>
> I'm not sure I entirely understand what you're proposing here, but it
> seems less wieldy than svn:externals.
>
> -Bill
>
>
>>
>>
>>>
>>> Duncan Murdoch
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>>> For additional commands, e-mail: users-help@subversion.tigris.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Versioning databases? (was General - Version questiosn?)
Posted by Anastasios Angelidis <vo...@videotron.ca>.
William Nagel wrote:
> On Nov 4, 2005, at 9:27 AM, Anastasios Angelidis wrote:
>
>> Next topic in order :D
>>
>> I'm thinking of scripting every element of a db: tables, stored
>> procs, functions, views for a particular project/component in their
>> own individual .sql files. To much maintenance?
>>
>> How do you guys go about this? c/c++, java etc... applications are
>> to easy to version! How about the database?
>
>
> My own work doesn't involve much database-related work, so you should
> take any advice I have with a grain of salt. That said, it seems to
> me that you should treat your database stuff the same way you would
> any other source files. Version the SQL files (in whatever
> granularity makes sense to your development process) and then also
> version whatever scripts are necessary to build functioning databases
> from those SQL files. That way you can just check out the repository
> and run a script to build databases for release or testing.
>
> Second, a bit of general mailing list advice: Whenever you start a
> new topic make sure you start it with a fresh email instead of by
> replying to another thread (even if that thread is one that you
> started). In addition to assuring that everyone's mail client will
> thread them properly, you make sure that you maximize the number of
> people who see the new topic. There may be people who could answer
> your new question who will never see it because they didn't care
> about the old topic and so are ignoring the thread.
Oh I just put general for something that is more version control related
then subversion related. Thats all.
>
> -Bill
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Versioning databases? (was General - Version questiosn?)
Posted by William Nagel <bi...@stagelogic.com>.
On Nov 4, 2005, at 9:27 AM, Anastasios Angelidis wrote:
> Next topic in order :D
>
> I'm thinking of scripting every element of a db: tables, stored
> procs, functions, views for a particular project/component in their
> own individual .sql files. To much maintenance?
>
> How do you guys go about this? c/c++, java etc... applications are
> to easy to version! How about the database?
My own work doesn't involve much database-related work, so you should
take any advice I have with a grain of salt. That said, it seems to
me that you should treat your database stuff the same way you would
any other source files. Version the SQL files (in whatever
granularity makes sense to your development process) and then also
version whatever scripts are necessary to build functioning databases
from those SQL files. That way you can just check out the repository
and run a script to build databases for release or testing.
Second, a bit of general mailing list advice: Whenever you start a
new topic make sure you start it with a fresh email instead of by
replying to another thread (even if that thread is one that you
started). In addition to assuring that everyone's mail client will
thread them properly, you make sure that you maximize the number of
people who see the new topic. There may be people who could answer
your new question who will never see it because they didn't care
about the old topic and so are ignoring the thread.
-Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: General - Versionioning databases?
Posted by Mark Parker <ma...@msdhub.com>.
Anastasios Angelidis wrote:
> Mark Parker wrote:
>
>> We do exactly that; everything goes in it's own folder (Functions/,
>> Tables/, Procedures/, etc.), and I developed a tool that puts them all
>> together (resolving interdependencies) into a single script that can
>> be used to "build" the database.
>>
>> To do an "upgrade" of an existing database, we do a "build" of the new
>> version, then use a db-sync tool (red-gate SQLCompare, if you're
>> wondering, but there's others out there) to make the existing database
>> look just like the new database.
>
>
> So you only keep create scripts?
>
> What if you do a column update on a table? It's not like you can rerun a
> create table on production. You only need to run a table update.
>
<snip>
Yes, we only keep create scripts. If we change some column on a table,
our tool (red-gate SQLCompare, as I mentioned) makes the change in the
production database. The process goes a little something like this:
1) run tool to make a create-script for the new version
2) run script to create a temporary copy of the new database
3) run SQLCompare to make production database look just like temp copy
4) remove temp copy
It's worked very well for us so far, but do note that SQLCompare isn't free.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: General - Versionioning databases?
Posted by Anastasios Angelidis <vo...@videotron.ca>.
Mark Parker wrote:
> We do exactly that; everything goes in it's own folder (Functions/,
> Tables/, Procedures/, etc.), and I developed a tool that puts them all
> together (resolving interdependencies) into a single script that can
> be used to "build" the database.
>
> To do an "upgrade" of an existing database, we do a "build" of the new
> version, then use a db-sync tool (red-gate SQLCompare, if you're
> wondering, but there's others out there) to make the existing database
> look just like the new database.
So you only keep create scripts?
What if you do a column update on a table? It's not like you can rerun a
create table on production. You only need to run a table update.
>
> We follow this model on many different databases, including some that
> have 300+ objects in them. It works very well for us.
>
> Mark
>
> Anastasios Angelidis wrote:
>
>> Next topic in order :D
>>
>> I'm thinking of scripting every element of a db: tables, stored
>> procs, functions, views for a particular project/component in their
>> own individual .sql files. To much maintenance?
>>
>> How do you guys go about this? c/c++, java etc... applications are to
>> easy to version! How about the database?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: General - Versionioning databases?
Posted by Mark Parker <ma...@msdhub.com>.
We do exactly that; everything goes in it's own folder (Functions/,
Tables/, Procedures/, etc.), and I developed a tool that puts them all
together (resolving interdependencies) into a single script that can be
used to "build" the database.
To do an "upgrade" of an existing database, we do a "build" of the new
version, then use a db-sync tool (red-gate SQLCompare, if you're
wondering, but there's others out there) to make the existing database
look just like the new database.
We follow this model on many different databases, including some that
have 300+ objects in them. It works very well for us.
Mark
Anastasios Angelidis wrote:
> Next topic in order :D
>
> I'm thinking of scripting every element of a db: tables, stored procs,
> functions, views for a particular project/component in their own
> individual .sql files. To much maintenance?
>
> How do you guys go about this? c/c++, java etc... applications are to
> easy to version! How about the database?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: General - Versionioning databases?
Posted by Anastasios Angelidis <vo...@videotron.ca>.
Next topic in order :D
I'm thinking of scripting every element of a db: tables, stored procs,
functions, views for a particular project/component in their own
individual .sql files. To much maintenance?
How do you guys go about this? c/c++, java etc... applications are to
easy to version! How about the database?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: General - Version questions?
Posted by William Nagel <bi...@stagelogic.com>.
On Nov 3, 2005, at 2:51 PM, Anastasios Angelidis wrote:
> Duncan Murdoch wrote:
>
>
>> On 11/3/2005 1:52 PM, Anastasios Angelidis wrote:
>>
>>
>>> Duncan Murdoch wrote:
>>>
>>>
>>>> On 11/3/2005 1:21 PM, Anastasios Angelidis wrote:
>>>>
>>>>
>>>>> This is some questions in general I'm hoping some of you can
>>>>> answer...
>>>>>
>>>>> Where I come from we do all versioning by hand and have come
>>>>> acustomed to certain procedures that we have implemented. I'm
>>>>> currently looking at implementing subversion for our version
>>>>> control and would like to see how I can integrate svn with out
>>>>> processes to possibly remove some of the manual work.
>>>>>
>>>>> 1- We have the following structure: Builds -> Projects ->
>>>>> Components -> Elements
>>>>>
>>>>> Build: Contains multiple projects
>>>>> Project: Contains multiple components (Executables, Dbs, Web
>>>>> etc...)
>>>>> Component: Contains multiple elements (source files etc...)
>>>>>
>>>>> We have a custom in house to that we track versions like 4.3.5
>>>>> in a sql DB.
>>>>>
>>>>> 1- Would I be able to track version numbers through svn,
>>>>> without having to rely on the sql db?
>>>>>
>>>>
>>>>
>>>>
>>>> Yes, it's very easy to record the version of every file in a
>>>> collection by making a copy of the collection to a tag
>>>> directory. (You don't actually make any physical copy, just a
>>>> logical copy.)
>>>>
>>>>
>>>>> 2- What would be the best way to handle a "build" as described
>>>>> above. As using 3 levels in a directory treet structure is
>>>>> cumbersome.
>>>>>
>>>>
>>>>
>>>>
>>>> There'd be no need to change your current directory structure.
>>>> Just import it into subversion and call it the trunk.
>>>>
>>>
>>>
>>> The problem with what we call a "build" is that it canot be
>>> represented well in a folder treet structure. Example I have a
>>> build called Apple_Carot_Cake...
>>>
>>> The Apple_Carot_Cake build hosts an Apple project and a Carot
>>> project.
>>>
>>> Then one day I decide to get fancy and create an
>>> Apple_Banana_Cake (Nasty tasting lol). This build would require
>>> the Apple project and a new Banana project.
>>>
>>> So now imagine that I would have to copy the Apple project to
>>> another trunk and have now to maintaine separate Apple projects.
>>> So when I need to update the Apple project I would then have to
>>> remember to merge to the Apple_Carot_Cake and the
>>> Apple_Banana_Cake apple trunks.
>>>
>>> Now that where versioning with the DB it's fairly easy to attach
>>> a "build" identifier to a project. But this still doesn't
>>> translate well to a tree folder structure like file explorer or
>>> svn. I'm thinking of "build" beeing parallel to projects. Can I
>>> assign a custom property called build to a project folder within
>>> subversion?
>>>
>>
>>
>> That sounds like what Subversion calls "Externals"; see http://
>> svnbook.red-bean.com/en/1.1/ch07s04.html. I've never used them
>> myself, so if you have any hard questions someone else will have
>> to help with them.
>>
>
> Humm I'm thinking more properties then externals. Cause even if I
> set externals. I will always have to rember to switch to the proper
> "aaple" project and still have to maintain 2 separate versions.
Not if you use externals properly.
If you have a layout like this:
MySVNRepo
--Apple
--Trunk
--Component 1
--Component 2
--etc
--Branches
--Tags
--Carrot
...
--Cake
--Banana
--Builds
--Apple_Carrot_Cake
-- svn:externals:
Apple -r50 http://svn.yourserver.com/MySVNRepo/Apple/Trunk
Carrot -r23 http://svn.yourserver.com/MySVNRepo/Carrot/Trunk
Cake -r34 http://svn.yourserver.com/MySVNRepo/Cake/Trunk
--Apple_Cake_Banana
-- svn:externals:
Apple -r92 http://svn.yourserver.com/MySVNRepo/Apple/Trunk
Banana -r103 http://svn.yourserver.com/MySVNRepo/Banana/Trunk
Cake -r243 http://svn.yourserver.com/MySVNRepo/Cake/Trunk
Then, anyone who checks out Apple_Cake_Banana will get the
Apple_Cake_Banana build will get Apple, Banana, and Cake at the
appropriate revisions. Also, since svn:externals is just a property
and properties are versioned, you can update a build to different
versions of each project by just changing the svn:externals property.
>
> This is what I'm thinking of doing...
>
> MySVNRepo
> |
> |
> |------ Apple <--- Attach a property "build" Build: Is used in
> the Apple_Carot_Cake.
> | |
> | |
> | |---- Branches
> | |
> | |---- Tags
> | |
> | |---- Trunk
> | |
> | |--- Component1
> | |--- Component2
> | |--- etc...
> |
> |
> |------ Carot <--- Attach a property "build" Build: Is used in
> the Apple_Carot_Cake.
> | |
> | ...
>
> So now when ever I move a project in a release branch I can adjust
> the build property. And if not mistaken properties are versioned as
> well.
I'm not sure I entirely understand what you're proposing here, but it
seems less wieldy than svn:externals.
-Bill
>
>
>>
>> Duncan Murdoch
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: General - Version questions?
Posted by Anastasios Angelidis <vo...@videotron.ca>.
Duncan Murdoch wrote:
> On 11/3/2005 1:52 PM, Anastasios Angelidis wrote:
>
>> Duncan Murdoch wrote:
>>
>>> On 11/3/2005 1:21 PM, Anastasios Angelidis wrote:
>>>
>>>> This is some questions in general I'm hoping some of you can answer...
>>>>
>>>> Where I come from we do all versioning by hand and have come
>>>> acustomed to certain procedures that we have implemented. I'm
>>>> currently looking at implementing subversion for our version
>>>> control and would like to see how I can integrate svn with out
>>>> processes to possibly remove some of the manual work.
>>>>
>>>> 1- We have the following structure: Builds -> Projects ->
>>>> Components -> Elements
>>>>
>>>> Build: Contains multiple projects
>>>> Project: Contains multiple components (Executables, Dbs, Web etc...)
>>>> Component: Contains multiple elements (source files etc...)
>>>>
>>>> We have a custom in house to that we track versions like 4.3.5 in a
>>>> sql DB.
>>>>
>>>> 1- Would I be able to track version numbers through svn, without
>>>> having to rely on the sql db?
>>>
>>>
>>>
>>> Yes, it's very easy to record the version of every file in a
>>> collection by making a copy of the collection to a tag directory.
>>> (You don't actually make any physical copy, just a logical copy.)
>>>
>>>> 2- What would be the best way to handle a "build" as described
>>>> above. As using 3 levels in a directory treet structure is cumbersome.
>>>
>>>
>>>
>>> There'd be no need to change your current directory structure. Just
>>> import it into subversion and call it the trunk.
>>
>>
>> The problem with what we call a "build" is that it canot be
>> represented well in a folder treet structure. Example I have a build
>> called Apple_Carot_Cake...
>>
>> The Apple_Carot_Cake build hosts an Apple project and a Carot project.
>>
>> Then one day I decide to get fancy and create an Apple_Banana_Cake
>> (Nasty tasting lol). This build would require the Apple project and a
>> new Banana project.
>>
>> So now imagine that I would have to copy the Apple project to another
>> trunk and have now to maintaine separate Apple projects. So when I
>> need to update the Apple project I would then have to remember to
>> merge to the Apple_Carot_Cake and the Apple_Banana_Cake apple trunks.
>>
>> Now that where versioning with the DB it's fairly easy to attach a
>> "build" identifier to a project. But this still doesn't translate
>> well to a tree folder structure like file explorer or svn. I'm
>> thinking of "build" beeing parallel to projects. Can I assign a
>> custom property called build to a project folder within subversion?
>
>
> That sounds like what Subversion calls "Externals"; see
> http://svnbook.red-bean.com/en/1.1/ch07s04.html. I've never used them
> myself, so if you have any hard questions someone else will have to
> help with them.
Humm I'm thinking more properties then externals. Cause even if I set
externals. I will always have to rember to switch to the proper "aaple"
project and still have to maintain 2 separate versions.
This is what I'm thinking of doing...
MySVNRepo
|
|
|------ Apple <--- Attach a property "build" Build: Is used in the
Apple_Carot_Cake.
| |
| |
| |---- Branches
| |
| |---- Tags
| |
| |---- Trunk
| |
| |--- Component1
| |--- Component2
| |--- etc...
|
|
|------ Carot <--- Attach a property "build" Build: Is used in the
Apple_Carot_Cake.
| |
| ...
So now when ever I move a project in a release branch I can adjust the
build property. And if not mistaken properties are versioned as well.
>
> Duncan Murdoch
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: General - Tree Structure.
Posted by Joshua Varner <jl...@gmail.com>.
On 11/3/05, Anastasios Angelidis <vo...@videotron.ca> wrote:
> Bare with me here... Trying to convert a manual version system to more
> or less automated...
>
> I'm thinking of creating the following tree structure. What do you guys
> think?
>
> Tree 1:
> projects/
> project_foo/
> trunk/
> component1
> foo.cpp
> bar.cpp
> component2
> foo.cpp
> bar.cpp
> ...
> branches/
> tags/
> project_bar/
> trunk/
> some_component1
> some_component2
> ...
> branches/
> tags/
>
> Tree 2:
> projects/
> project_foo/
> component1
> trunk/
> foo.cpp
> bar.cpp
> branches/
> tags/
> component2
> project_bar/
> some_component1
> trunk/
> foo.cpp
> bar.cpp
> branches/
> tags/
> some_component2
>
> I'm thinking tree 2 is maybe a bit to deep?
>
It depends on if you want to branch the components separately or not.
If yes tree 2 is probably better, otherwise tree 1.
Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: General - Tree Structure.
Posted by Anastasios Angelidis <vo...@videotron.ca>.
Bare with me here... Trying to convert a manual version system to more
or less automated...
I'm thinking of creating the following tree structure. What do you guys
think?
Tree 1:
projects/
project_foo/
trunk/
component1
foo.cpp
bar.cpp
component2
foo.cpp
bar.cpp
...
branches/
tags/
project_bar/
trunk/
some_component1
some_component2
...
branches/
tags/
Tree 2:
projects/
project_foo/
component1
trunk/
foo.cpp
bar.cpp
branches/
tags/
component2
project_bar/
some_component1
trunk/
foo.cpp
bar.cpp
branches/
tags/
some_component2
I'm thinking tree 2 is maybe a bit to deep?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: General - Version questions?
Posted by Anastasios Angelidis <vo...@videotron.ca>.
Ryan Schmidt wrote:
> On Nov 3, 2005, at 19:56, Duncan Murdoch wrote:
>
>> On 11/3/2005 1:52 PM, Anastasios Angelidis wrote:
>>
>>> Duncan Murdoch wrote:
>>>
>>>> On 11/3/2005 1:21 PM, Anastasios Angelidis wrote:
>>>>
>>>>> Where I come from we do all versioning by hand and have come
>>>>> acustomed to certain procedures that we have implemented. I'm
>>>>> currently looking at implementing subversion for our version
>>>>> control and would like to see how I can integrate svn with out
>>>>> processes to possibly remove some of the manual work.
>>>>>
>>>>> 1- We have the following structure: Builds -> Projects ->
>>>>> Components -> Elements
>>>>>
>>>>> Build: Contains multiple projects
>>>>> Project: Contains multiple components (Executables, Dbs, Web etc...)
>>>>> Component: Contains multiple elements (source files etc...)
>>>>>
>>>>> We have a custom in house to that we track versions like 4.3.5 in
>>>>> a sql DB.
>>>>>
>>>>> 1- Would I be able to track version numbers through svn, without
>>>>> having to rely on the sql db?
>>>>
>>>>
>>>> Yes, it's very easy to record the version of every file in a
>>>> collection by making a copy of the collection to a tag directory.
>>>> (You don't actually make any physical copy, just a logical copy.)
>>>>
>>>>
>>>>> 2- What would be the best way to handle a "build" as described
>>>>> above. As using 3 levels in a directory treet structure is
>>>>> cumbersome.
>>>>
>>>>
>>>> There'd be no need to change your current directory structure.
>>>> Just import it into subversion and call it the trunk.
>>>
>>>
>>> The problem with what we call a "build" is that it canot be
>>> represented well in a folder treet structure. Example I have a
>>> build called Apple_Carot_Cake...
>>> The Apple_Carot_Cake build hosts an Apple project and a Carot project.
>>> Then one day I decide to get fancy and create an Apple_Banana_Cake
>>> (Nasty tasting lol). This build would require the Apple project and
>>> a new Banana project.
>>> So now imagine that I would have to copy the Apple project to
>>> another trunk and have now to maintaine separate Apple projects. So
>>> when I need to update the Apple project I would then have to
>>> remember to merge to the Apple_Carot_Cake and the Apple_Banana_Cake
>>> apple trunks.
>>> Now that where versioning with the DB it's fairly easy to attach a
>>> "build" identifier to a project. But this still doesn't translate
>>> well to a tree folder structure like file explorer or svn. I'm
>>> thinking of "build" beeing parallel to projects. Can I assign a
>>> custom property called build to a project folder within subversion?
>>
>>
>> That sounds like what Subversion calls "Externals"; see http://
>> svnbook.red-bean.com/en/1.1/ch07s04.html. I've never used them
>> myself, so if you have any hard questions someone else will have to
>> help with them.
>
>
> I agree. Externals. Perhaps a repo layout like this:
>
> /repo/
> projects/
> apple/
> trunk/
> branches/
> tags/
> banana/
> trunk/
> branches/
> tags/
> carrot/
> trunk/
> branches/
> tags/
> builds/
> apple-carrot-cake/
> external link to /repo/projects/apple/trunk
> external link to /repo/projects/carrot/trunk
> maybe a Makefile
> apple-banana-cake/
> external link to /repo/projects/apple/trunk
> external link to /repo/projects/banana/trunk
> maybe a Makefile
>
> Now, if the apple-carrot-cake build references apple and carrot
> trunks, as above, then you'll have problems if in the future you want
> to look at the apple-carrot-cake build, because it'll reference the
> apple and carrot trunks as they are now, not as they were when the
> build was created. So you may want to set the externals to link to
> specific branches or specific tags of apple and carrot.
>
> Will the apple-carrot-cake build be made once or multiple times? If
> multiple times, you may want to keep track of those builds in
> branches and tags too:
>
> /repo/
> projects/
> apple/
> trunk/
> branches/
> tags/
> banana/
> trunk/
> branches/
> tags/
> carrot/
> trunk/
> branches/
> tags/
> builds/
> apple-carrot-cake/
> trunk/
> external link to /repo/projects/apple/trunk
> external link to /repo/projects/carrot/trunk
> maybe a Makefile
> branches/
> tags/
> apple-banana-cake/
> trunk/
> external link to /repo/projects/apple/trunk
> external link to /repo/projects/banana/trunk
> maybe a Makefile
> branches/
> tags/
>
> If you do it that way, and use the svncopy script to create tags of
> the builds, then you can keep the externals linked to the trunk, and
> svncopy will take care of linking the tagged versions to the specific
> version of trunk that was current at the time.
I see so the trunk in the build, will point to the current trunk of each
project and the branches of the build will point to the specific
branches in the projects?
How about using properties like:
MySVNRepo
|
|
|------ Apple <--- Attach a property "build" Build: Is used in the
Apple_Carot_Cake.
| |
| |
| |---- Branches
| |
| |---- Tags
| |
| |---- Trunk
| |
| |--- Component1
| |--- Component2
| |--- etc...
|
|
|------ Carot <--- Attach a property "build" Build: Is used in the
Apple_Carot_Cake.
| |
| ...
So now when ever I move a project in a release branch I can adjust the
build property. And if not mistaken properties are versioned as well.
Unless you still think that externals are best used in this case.
Thanks
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: General - Version questions?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 3, 2005, at 19:56, Duncan Murdoch wrote:
> On 11/3/2005 1:52 PM, Anastasios Angelidis wrote:
>
>> Duncan Murdoch wrote:
>>
>>> On 11/3/2005 1:21 PM, Anastasios Angelidis wrote:
>>>
>>>> Where I come from we do all versioning by hand and have come
>>>> acustomed to certain procedures that we have implemented. I'm
>>>> currently looking at implementing subversion for our version
>>>> control and would like to see how I can integrate svn with out
>>>> processes to possibly remove some of the manual work.
>>>>
>>>> 1- We have the following structure: Builds -> Projects ->
>>>> Components -> Elements
>>>>
>>>> Build: Contains multiple projects
>>>> Project: Contains multiple components (Executables, Dbs, Web
>>>> etc...)
>>>> Component: Contains multiple elements (source files etc...)
>>>>
>>>> We have a custom in house to that we track versions like 4.3.5
>>>> in a sql DB.
>>>>
>>>> 1- Would I be able to track version numbers through svn, without
>>>> having to rely on the sql db?
>>>
>>> Yes, it's very easy to record the version of every file in a
>>> collection by making a copy of the collection to a tag
>>> directory. (You don't actually make any physical copy, just a
>>> logical copy.)
>>>
>>>
>>>> 2- What would be the best way to handle a "build" as described
>>>> above. As using 3 levels in a directory treet structure is
>>>> cumbersome.
>>>
>>> There'd be no need to change your current directory structure.
>>> Just import it into subversion and call it the trunk.
>>
>> The problem with what we call a "build" is that it canot be
>> represented well in a folder treet structure. Example I have a
>> build called Apple_Carot_Cake...
>> The Apple_Carot_Cake build hosts an Apple project and a Carot
>> project.
>> Then one day I decide to get fancy and create an Apple_Banana_Cake
>> (Nasty tasting lol). This build would require the Apple project
>> and a new Banana project.
>> So now imagine that I would have to copy the Apple project to
>> another trunk and have now to maintaine separate Apple projects.
>> So when I need to update the Apple project I would then have to
>> remember to merge to the Apple_Carot_Cake and the
>> Apple_Banana_Cake apple trunks.
>> Now that where versioning with the DB it's fairly easy to attach a
>> "build" identifier to a project. But this still doesn't translate
>> well to a tree folder structure like file explorer or svn. I'm
>> thinking of "build" beeing parallel to projects. Can I assign a
>> custom property called build to a project folder within subversion?
>
> That sounds like what Subversion calls "Externals"; see http://
> svnbook.red-bean.com/en/1.1/ch07s04.html. I've never used them
> myself, so if you have any hard questions someone else will have to
> help with them.
I agree. Externals. Perhaps a repo layout like this:
/repo/
projects/
apple/
trunk/
branches/
tags/
banana/
trunk/
branches/
tags/
carrot/
trunk/
branches/
tags/
builds/
apple-carrot-cake/
external link to /repo/projects/apple/trunk
external link to /repo/projects/carrot/trunk
maybe a Makefile
apple-banana-cake/
external link to /repo/projects/apple/trunk
external link to /repo/projects/banana/trunk
maybe a Makefile
Now, if the apple-carrot-cake build references apple and carrot
trunks, as above, then you'll have problems if in the future you want
to look at the apple-carrot-cake build, because it'll reference the
apple and carrot trunks as they are now, not as they were when the
build was created. So you may want to set the externals to link to
specific branches or specific tags of apple and carrot.
Will the apple-carrot-cake build be made once or multiple times? If
multiple times, you may want to keep track of those builds in
branches and tags too:
/repo/
projects/
apple/
trunk/
branches/
tags/
banana/
trunk/
branches/
tags/
carrot/
trunk/
branches/
tags/
builds/
apple-carrot-cake/
trunk/
external link to /repo/projects/apple/trunk
external link to /repo/projects/carrot/trunk
maybe a Makefile
branches/
tags/
apple-banana-cake/
trunk/
external link to /repo/projects/apple/trunk
external link to /repo/projects/banana/trunk
maybe a Makefile
branches/
tags/
If you do it that way, and use the svncopy script to create tags of
the builds, then you can keep the externals linked to the trunk, and
svncopy will take care of linking the tagged versions to the specific
version of trunk that was current at the time.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: General - Version questions?
Posted by Duncan Murdoch <su...@murdoch-sutherland.com>.
On 11/3/2005 1:52 PM, Anastasios Angelidis wrote:
> Duncan Murdoch wrote:
>
>> On 11/3/2005 1:21 PM, Anastasios Angelidis wrote:
>>
>>> This is some questions in general I'm hoping some of you can answer...
>>>
>>> Where I come from we do all versioning by hand and have come
>>> acustomed to certain procedures that we have implemented. I'm
>>> currently looking at implementing subversion for our version control
>>> and would like to see how I can integrate svn with out processes to
>>> possibly remove some of the manual work.
>>>
>>> 1- We have the following structure: Builds -> Projects -> Components
>>> -> Elements
>>>
>>> Build: Contains multiple projects
>>> Project: Contains multiple components (Executables, Dbs, Web etc...)
>>> Component: Contains multiple elements (source files etc...)
>>>
>>> We have a custom in house to that we track versions like 4.3.5 in a
>>> sql DB.
>>>
>>> 1- Would I be able to track version numbers through svn, without
>>> having to rely on the sql db?
>>
>>
>> Yes, it's very easy to record the version of every file in a
>> collection by making a copy of the collection to a tag directory.
>> (You don't actually make any physical copy, just a logical copy.)
>>
>>> 2- What would be the best way to handle a "build" as described above.
>>> As using 3 levels in a directory treet structure is cumbersome.
>>
>>
>> There'd be no need to change your current directory structure. Just
>> import it into subversion and call it the trunk.
>
> The problem with what we call a "build" is that it canot be represented
> well in a folder treet structure. Example I have a build called
> Apple_Carot_Cake...
>
> The Apple_Carot_Cake build hosts an Apple project and a Carot project.
>
> Then one day I decide to get fancy and create an Apple_Banana_Cake
> (Nasty tasting lol). This build would require the Apple project and a
> new Banana project.
>
> So now imagine that I would have to copy the Apple project to another
> trunk and have now to maintaine separate Apple projects. So when I need
> to update the Apple project I would then have to remember to merge to
> the Apple_Carot_Cake and the Apple_Banana_Cake apple trunks.
>
> Now that where versioning with the DB it's fairly easy to attach a
> "build" identifier to a project. But this still doesn't translate well
> to a tree folder structure like file explorer or svn. I'm thinking of
> "build" beeing parallel to projects. Can I assign a custom property
> called build to a project folder within subversion?
That sounds like what Subversion calls "Externals"; see
http://svnbook.red-bean.com/en/1.1/ch07s04.html. I've never used them
myself, so if you have any hard questions someone else will have to help
with them.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: General - Version questions?
Posted by Anastasios Angelidis <vo...@videotron.ca>.
Duncan Murdoch wrote:
> On 11/3/2005 1:21 PM, Anastasios Angelidis wrote:
>
>> This is some questions in general I'm hoping some of you can answer...
>>
>> Where I come from we do all versioning by hand and have come
>> acustomed to certain procedures that we have implemented. I'm
>> currently looking at implementing subversion for our version control
>> and would like to see how I can integrate svn with out processes to
>> possibly remove some of the manual work.
>>
>> 1- We have the following structure: Builds -> Projects -> Components
>> -> Elements
>>
>> Build: Contains multiple projects
>> Project: Contains multiple components (Executables, Dbs, Web etc...)
>> Component: Contains multiple elements (source files etc...)
>>
>> We have a custom in house to that we track versions like 4.3.5 in a
>> sql DB.
>>
>> 1- Would I be able to track version numbers through svn, without
>> having to rely on the sql db?
>
>
> Yes, it's very easy to record the version of every file in a
> collection by making a copy of the collection to a tag directory.
> (You don't actually make any physical copy, just a logical copy.)
>
>> 2- What would be the best way to handle a "build" as described above.
>> As using 3 levels in a directory treet structure is cumbersome.
>
>
> There'd be no need to change your current directory structure. Just
> import it into subversion and call it the trunk.
The problem with what we call a "build" is that it canot be represented
well in a folder treet structure. Example I have a build called
Apple_Carot_Cake...
The Apple_Carot_Cake build hosts an Apple project and a Carot project.
Then one day I decide to get fancy and create an Apple_Banana_Cake
(Nasty tasting lol). This build would require the Apple project and a
new Banana project.
So now imagine that I would have to copy the Apple project to another
trunk and have now to maintaine separate Apple projects. So when I need
to update the Apple project I would then have to remember to merge to
the Apple_Carot_Cake and the Apple_Banana_Cake apple trunks.
Now that where versioning with the DB it's fairly easy to attach a
"build" identifier to a project. But this still doesn't translate well
to a tree folder structure like file explorer or svn. I'm thinking of
"build" beeing parallel to projects. Can I assign a custom property
called build to a project folder within subversion?
>
> Duncan Murdoch
>
>>
>> Thanks
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: General - Version questions?
Posted by Duncan Murdoch <su...@murdoch-sutherland.com>.
On 11/3/2005 1:21 PM, Anastasios Angelidis wrote:
> This is some questions in general I'm hoping some of you can answer...
>
> Where I come from we do all versioning by hand and have come acustomed
> to certain procedures that we have implemented. I'm currently looking at
> implementing subversion for our version control and would like to see
> how I can integrate svn with out processes to possibly remove some of
> the manual work.
>
> 1- We have the following structure: Builds -> Projects -> Components ->
> Elements
>
> Build: Contains multiple projects
> Project: Contains multiple components (Executables, Dbs, Web etc...)
> Component: Contains multiple elements (source files etc...)
>
> We have a custom in house to that we track versions like 4.3.5 in a sql DB.
>
> 1- Would I be able to track version numbers through svn, without having
> to rely on the sql db?
Yes, it's very easy to record the version of every file in a collection
by making a copy of the collection to a tag directory. (You don't
actually make any physical copy, just a logical copy.)
> 2- What would be the best way to handle a "build" as described above. As
> using 3 levels in a directory treet structure is cumbersome.
There'd be no need to change your current directory structure. Just
import it into subversion and call it the trunk.
Duncan Murdoch
>
> Thanks
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org