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
Received on Thu Nov 3 21:00:26 2005