git repo structure

[Jochen G.]

currently we have all the old stuff as well as support things in the repo:
branches bugzilla-patch database gcd pydjango README.txt

Since with git one cannot clone subdirs one would always have all that
in ones git clone. Not so nice.

I guess we should split out the pydjango-dir into a new repo. And maybe
give it a new name while we are at it ? gcd-django ?

How about the database directory ? Not necessarily as needed in a dev
process by others, but needed for deployment and the core developers ?
Do we consider that as a separate repo since it is not python/django ?
Or add that to the pydjango repo as a subdir ?

Or do a gcd-support repo where we put both database and bugzilla-patch
as subdirs (and potentially other things we want to store) ?

Jochen

[Alexandros Diamantidis]

* Jochen G. [2012-10-03 11:12]:

> I guess we should split out the pydjango-dir into a new repo. And maybe
> give it a new name while we are at it ? gcd-django ?

Yes, good idea! I see you already did that ;-)

> How about the database directory ? Not necessarily as needed in a dev
> process by others, but needed for deployment and the core developers ?

Even for others it's useful, since it's nice to be able to keep a local
installation's db updated. Having it in the same repo as the code seems
better to me, since the main code and the database scripts need to stay
in sync.

The best solution is probably to forget about custom scripts and start
using South: http://south.readthedocs.org/en/latest/index.html
It seems very convenient...

> Or do a gcd-support repo where we put both database and bugzilla-patch
> as subdirs (and potentially other things we want to store) ?

Yes, that too. Although I think that the scripts from database/scripts
might also fit better as part of the main repo.

Thanks,
Alexandros

[Jochen G.]

Am 03.10.2012 17:42, schrieb Alexandros Diamantidis:
> Even for others it's useful, since it's nice to be able to keep a local
> installation's db updated. Having it in the same repo as the code seems
> better to me, since the main code and the database scripts need to stay
> in sync.

But it is not python code.

> The best solution is probably to forget about custom scripts and start
> using South: http://south.readthedocs.org/en/latest/index.html
> It seems very convenient...

probably

>> Or do a gcd-support repo where we put both database and bugzilla-patch
>> as subdirs (and potentially other things we want to store) ?
>
> Yes, that too. Although I think that the scripts from database/scripts
> might also fit better as part of the main repo.

These scripts have to do with the production site, you don't need them
at a dev site. So it makes some sense to split them.

Jochen

[Henry Andrews]

South is a much better solution than what we've been doing, and in the time since we started the project it's become essentially the standard for schema management (I've used it extensively within the last year).  I would recommend archiving the old DB scripts wherever (but do audit the python code that's currently in that tree, as I think some of it is more generally useful) and adding a baseline south migration to the gcd-django tree.

South would not have been able to handle the crazy stuff we needed to do to migrate into Django from the old DB, but it is fine for all of the more recent DB schema work.  If we ever did want to reconstruct more change history, that would probably be a separate set of DB scripts, but that's the only thing.

thanks,

-henry

---

From: Jochen G. <gcd...@garcke.de>
To: gcd-...@googlegroups.com
Sent: Wednesday, October 3, 2012 9:06 AM
Subject: Re: [gcd-tech] git repo structure

--
GCD-Tech mailing list - gcd-...@googlegroups.com
To unsubscribe send email to gcd-tech+unsub...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/gcd-tech

[Jochen G.]

Am 03.10.2012 19:35, schrieb Henry Andrews:
> more recent DB schema work. If we ever did want to reconstruct more
> change history, that would probably be a separate set of DB scripts, but
> that's the only thing.

Btw, I more or less fixed the existing problems with the reconstructing
of the change history at some point. But I want to use two old dumps to
build it, the oldest Jon could find as the base, and than the last of
the old site on top of that. That way we can also generate records for
adds by indexer, which otherwise would go to the anon-user. But, yeah,
separate scripts, an no (permanent) DB changes needed anyway.

Jochen

[Henry Andrews]

That is awesome news!  That whole thing drove me absolutely mad near the end of 2010.  I thought I had it, and then I just could not get the test run to work out, and couldn't figure out why, and ran out of steam.

I look forward to whenever you can get the necessary dumps to run the scripts!

thanks,

-henry

---

From: Jochen G. <gcd...@garcke.de>
To: gcd-...@googlegroups.com

Sent: Wednesday, October 3, 2012 10:40 AM

Subject: Re: [gcd-tech] git repo structure