Skip to main content

Repository Structure

2 replies [Last post]
khendry
Offline
Joined: 2004-08-13
Points: 0

Why are there so many massive binary files included in the RI source tree? Is there any effort underway to extricate these files into a more appropriate location? Mixing binary and source flies like this is causing me a great deal of sadness. I like to generally reduce my sadness while correspondingly increasing my joy. Any chance this is in progress or being thought about?

While your little checkout script is helpful in some respects, it doesn't work when someone tries to use git with the repository. This is probably a futile request, but if I don't ask it'll probably never happen.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
csweeney
Offline
Joined: 2009-04-11
Points: 0

Actually, we are in the process of doing just that. Hope to do something by week end.

csweeney
Offline
Joined: 2009-04-11
Points: 0

This is the current proposal:

Summary:
- create https://community.cablelabs.com/svn/OCAPRI/support_files
- after making sure that appropriate components still compile, move
non-code related files/directories into
https://community.cablelabs.com/svn/OCAPRI/support_files, with
appropriate README notes in prior locations.
examples:
https://community.cablelabs.com/svn/OCAPRI/trunk/SDK/3rdParty
https://community.cablelabs.com/svn/OCAPRI/trunk/common/3rdParty/
https://community.cablelabs.com/svn/OCAPRI/trunk/common/doc/
https://community.cablelabs.com/svn/OCAPRI/trunk/opensource_documents/
https://community.cablelabs.com/svn/OCAPRI/trunk/other_documents/
https://community.cablelabs.com/svn/OCAPRI/trunk/release_notes/

NOTE: My intent is to perform a single commit containing all of these changes.

Background:
There is a desire to avoid having mergeinfo properties changes appear
on files/directories that appear to be not related to code changes.
A major source of said mergeinfo properties is utilizing "sparse
checkout" working copies when performing a merge.
However, we have been using "sparse checkout" working copies to
mitigate the time/disk requirements of checking out working copies.
Thus, we need to pare down the files included in the code root
("trunk") of the repository.
Arguments have been made for eliminating certain files, and for
keeping them in the repository.
It is not a question of repository size - just the set of files
contained in the trunk.
Files that remain in the trunk are:
-needed for compilation/execution of a component (e.g. the RI, or SDK).
-generally source code (this is not a hard and fast rule).
-somewhat likely to need to be revisioned (again, not hard and fast).
Moving candidate files resolves the primary problem, while insuring
that files are available, not likely to "be lost", and maintainable.