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...
|------ Apple <--- Attach a property "build" Build: Is used in the
| |---- Branches
| |---- Tags
| |---- Trunk
| |--- Component1
| |--- Component2
| |--- etc...
|------ Carot <--- Attach a property "build" Build: Is used in the
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: firstname.lastname@example.org
> For additional commands, e-mail: email@example.com
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Nov 3 20:53:59 2005