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
Received on Fri Nov 4 03:00:42 2005