[asterisk-scf-dev] Proposed Naming Conventions

[Mark Michelson]

On 11/21/2011 05:04 PM, David M. Lee wrote:
> On Nov 21, 2011, at 4:34 PM, Mark Michelson wrote:
>
>> Per https://issues.asterisk.org/jira/browse/ASTSCF-292, I have been tasked with streamlining the naming convention for file, component, and repository names in Asterisk SCF. If you take a look at the issue, then you can see where some of the inconsistencies lie.
>>
>> My proposal is the following:
>>
>> 1. All repository, file, non-component library, and component names will be in UpperCamelCase.
> Renaming the repositories on the server would make it impractical to rebuild older versions, since the only way to build currently is with integrated builds.  Pre-rename revisions of the gitall script will no longer work, since they refer to repos that no longer exist.  And rolling back to pre-rename will not only involve the git trickery to checkout at a particular timestamp, but also include renaming local repositories to match whatever they were pre-rename.
> This may not be important since we're in pre-beta, but demonstrates that it will be important document the decision on the wiki and enforce consistency.
>
> I wonder if a non-integrated build would have been more flexible.  Then they would/could be built independently, and individual repository names wouldn't matter.  You still have to checkout each repo to the revision you wish to build, but at least you wouldn't have to worry about how the repositories are named on the local system.
You raise some valid concerns. My initial thought was that symlinks 
could be used to get to the real repo if an old location were specified, 
but Googling has revealed that git does not follow symlinks.

I think the fact we're still pre-beta means a disruption like this is 
not too bad. There are not too many users who will be affected by the 
changes. This should only ever happen this one time since guidelines 
will be in place from now on, so it's good to get this sort of hassle 
out of the way early rather than down the road when we have a full 
release out.

To address one of your points, pre-rename versions of the gitall script 
actually will work, I believe. The gitall script will automatically pull 
down a newer version of itself when run and then run the newer version. 
The net result will be some extra unused repos locally, but the script 
will actually run properly and get the new renamed repos.

The phrase "rolling back to pre-rename" is vague. Do you mean rolling 
back to pre-rename commits within a repo? If so, why would rolling back 
to pre-rename commits involve git trickery? Wouldn't the commit history 
be the same even if the repo were moved? Could you not roll back to a 
commit or tag the same way you normally would? Or are you referring to 
attempting to roll back the gitall script or something else entirely?

Mark Michelson