[drupal-devel] Cleaner Directory structure
On 5/12/05, K B <kbahey@gmail.com> wrote:
All this does not need to go in CVS as it is. The CVS can largely remain as it is. What the developers see when committing code and what the end user (site admin) sees are two different things.
The script that creates the tarball can deal with all this and everything else remains the same.
Not sure that I understand you there. The current situation in Drupal is that the contents of the tarball are exactly the same as the contents of CVS (except that CVS is more up-to-date). Are you saying that this will no longer be the case? Do you mean that checking out Drupal core will now have a different result to downloading a tarball of Drupal core? My understanding was that the Drupal core CVS repository would have everything under /public_html, and that the Drupal core tarball would have the same (this is how it is now). Why would you want to change this? Doing so would only confuse people. Jaza.
He's saying the script that produces the tarball would have to be modified to get the files from different directories. Once gotten, it would go on to produce the same expected output. Downloaders will be fine. On 5/12/05, Jeremy Epstein <jazepstein@gmail.com> wrote:
On 5/12/05, K B <kbahey@gmail.com> wrote:
All this does not need to go in CVS as it is. The CVS can largely remain as it is. What the developers see when committing code and what the end user (site admin) sees are two different things.
The script that creates the tarball can deal with all this and everything else remains the same.
Not sure that I understand you there. The current situation in Drupal is that the contents of the tarball are exactly the same as the contents of CVS (except that CVS is more up-to-date). Are you saying that this will no longer be the case? Do you mean that checking out Drupal core will now have a different result to downloading a tarball of Drupal core?
My understanding was that the Drupal core CVS repository would have everything under /public_html, and that the Drupal core tarball would have the same (this is how it is now). Why would you want to change this? Doing so would only confuse people.
Jaza.
Not sure that I understand you there. The current situation in Drupal is that the contents of the tarball are exactly the same as the contents of CVS (except that CVS is more up-to-date). Are you saying that this will no longer be the case? Do you mean that checking out Drupal core will now have a different result to downloading a tarball of Drupal core?
My understanding was that the Drupal core CVS repository would have everything under /public_html, and that the Drupal core tarball would have the same (this is how it is now). Why would you want to change this? Doing so would only confuse people.
Agreed. If we go ahead with this, the directory structure in CVS should match the structure in the tarball. If not, we're asking for trouble, and it is a nightmare for people using CVS to maintain/update their sites. -- Dries Buytaert :: http://www.buytaert.net/
On 5/12/05, Dries Buytaert <dries@buytaert.net> wrote:
Not sure that I understand you there. The current situation in Drupal is that the contents of the tarball are exactly the same as the contents of CVS (except that CVS is more up-to-date). Are you saying that this will no longer be the case? Do you mean that checking out Drupal core will now have a different result to downloading a tarball of Drupal core?
My understanding was that the Drupal core CVS repository would have everything under /public_html, and that the Drupal core tarball would have the same (this is how it is now). Why would you want to change this? Doing so would only confuse people.
Agreed. If we go ahead with this, the directory structure in CVS should match the structure in the tarball. If not, we're asking for trouble, and it is a nightmare for people using CVS to maintain/update their sites.
Dries I hear what you are saying, but the idea here is to improve this for the end user and not be obstructed because of developers (who already know what they are doing and can work around it). This leaves several options: 1. Go ahead with this new scheme (drupal and local) and reorganize the CVS to match. There is some work involved at the CVS backedn level, making it match the proposed scheme. 2. Write a script to move directories after a CVS checkout. This seems cumbersome, since a cvs update will not work. 3. Adrian's install handles upgrades (need details on when it will be available and whether upgrades will be seemless) 4. Forget this whole new directory structure thing, and continue to deal with complaints about upgrades being dangerous and difficult. What do you think?
My understanding was that the Drupal core CVS repository would have everything under /public_html, and that the Drupal core tarball would have the same (this is how it is now). Why would you want to change this? Doing so would only confuse people.
Agreed. If we go ahead with this, the directory structure in CVS should match the structure in the tarball. If not, we're asking for trouble, and it is a nightmare for people using CVS to maintain/update their sites. My suggestion would be to keep the core directory structure as is for all of the above reasons and to provide flexibility for different packagers. Changing the CVS layout will cause a lot of trouble most notably history loss.
The real solution for ease of installation and maintenance will, hopefully, come with the installer Adrian is working on. He said it is his priority to make its appearance as soon as possible. With him we are working together on modules, themes and theme-engines (package) dependencies, and ways to package and manage those. A solution like that allowing your preferred directory layout will meet the 'cleaner directory structure' goals. In the end cleaner depends on the context of installation - shared hosting, hosting provider like Bryght, dedicated services similar to what I run in house, local policies ... Over the weekend I can prepare a patch for my earlier suggestion. It doesn't solve all issues, but at least it goes some way towards allowing a more flexible layout. Maybe we could prepare a couple of scripts to modify the directory structure to some of the usage scenarios. I wouldn't like to modify something which works and has it's merits for a simple but not all encompassing convenience.
So, can I conclude that we never reached concensus on this change? I hope that Adrian's install takes care of this issue (having an unchangable set of files for Drupal core in a single directory, and all changed files in another). Adrian, any estimated time on when your installer would be ready? Is this a 4.7 thing.
K B wrote:
So, can I conclude that we never reached concensus on this change?
I hope that Adrian's install takes care of this issue (having an unchangable set of files for Drupal core in a single directory, and all changed files in another).
Adrian, any estimated time on when your installer would be ready? Is this a 4.7 thing.
It's definately a 4.7 thing. So it will be ready some time before 4.7 is released. Work on most of the components have been written already, and just need to be integrated with each other, and Drupal core. So the project might take anywhere from 1 month, to three months before it reaches completion (completion being the core requirements, ie: be able to install core through a wizard)
As long as it is part of 4.7, then I think there is no need urgent need for my solution. I assume that your installer will eliminate the current model where the instructions say "do not copy files over what is already there" causing a lot of grief on upgrades. Am I right? On 5/15/05, Adrian Rossouw <adrian@bryght.com> wrote:
K B wrote:
So, can I conclude that we never reached concensus on this change?
I hope that Adrian's install takes care of this issue (having an unchangable set of files for Drupal core in a single directory, and all changed files in another).
Adrian, any estimated time on when your installer would be ready? Is this a 4.7 thing.
It's definately a 4.7 thing. So it will be ready some time before 4.7 is released. Work on most of the components have been written already, and just need to be integrated with each other, and Drupal core.
So the project might take anywhere from 1 month, to three months before it reaches completion (completion being the core requirements, ie: be able to install core through a wizard)
K B wrote:
As long as it is part of 4.7, then I think there is no need urgent need for my solution.
I assume that your installer will eliminate the current model where the instructions say "do not copy files over what is already there" causing a lot of grief on upgrades. Am I right?
Indeed. It is built to disable functionality that is out of date, including core. I want to make it so that upgrades become painless, and can even be totally automated.
participants (6)
-
Adrian Rossouw -
Dries Buytaert -
Earl Dunovant -
Jeremy Epstein -
K B -
vlado