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
Received on Thu Nov 3 20:45:19 2005