On Mon, Oct 6, 2008 at 10:41 AM, Giel van Schijndel [EMAIL PROTECTED] wrote:
Why do we even need the videos under revision control?
People asked the same question about the data/ stuff. It quickly
became clear that not having data under version control invited to
total chaos. Just image when
Per Inge Mathisen schreef:
On Mon, Oct 6, 2008 at 1:23 AM, Giel van Schijndel [EMAIL PROTECTED] wrote:
Per Inge Mathisen schreef:
BTW - what will happen to existing, checked out working copies if the
current contents of trunk/ is moved?
I don't want my existing working copies to die a sudden
Per Inge Mathisen schreef:
On Mon, Oct 6, 2008 at 10:41 AM, Giel van Schijndel [EMAIL PROTECTED] wrote:
Why do we even need the videos under revision control?
People asked the same question about the data/ stuff. It quickly
became clear that not having data under version control invited to
On Mon, Oct 6, 2008 at 11:02 AM, Giel van Schijndel [EMAIL PROTECTED] wrote:
Ok, point taken. However I'd like to suggest that we use a *separate*
repository for those videos. I would personally prefer a git repository.
Because of its speed with cloning and checking out different revisions
On Sun, Oct 5, 2008 at 7:50 AM, bugs buggy [EMAIL PROTECTED] wrote:
With the upcoming release of the FMV patch in trunk, *before* we add the
fmvs into the repo, I would like to confirm the data structure.
trunk/data (only pumpkin official stuff, + derivatives of their work?)
trunk/code or
Am Sonntag, 5. Oktober 2008 07:50:39 schrieb bugs buggy:
With the upcoming release of the FMV patch in trunk, *before* we add the
fmvs into the repo, I would like to confirm the data structure.
trunk/data (only pumpkin official stuff, + derivatives of their work?)
trunk/code or trunk/source
Per Inge Mathisen schreef:
On Sun, Oct 5, 2008 at 7:50 AM, bugs buggy [EMAIL PROTECTED] wrote:
With the upcoming release of the FMV patch in trunk, *before* we add the
fmvs into the repo, I would like to confirm the data structure.
trunk/data (only pumpkin official stuff, + derivatives of
On Sunday, 5 October 2008 at 1:50, bugs buggy wrote:
With the upcoming release of the FMV patch in trunk, *before* we add the
fmvs into the repo, I would like to confirm the data structure.
Question: Why do you want to add those to SVN? I can understand the rest of the
data (well, perhaps not
On Sun, Oct 5, 2008 at 2:43 PM, Giel van Schijndel [EMAIL PROTECTED] wrote:
I would prefer to have tools as part of the code/ directory, since
they are (or should be) closely linked to the rest of the code.
Agreed. I would also prefer to use source instead of code.
This is imprecise, because
Am Sonntag, 5. Oktober 2008 16:47:47 schrieb Per Inge Mathisen:
On Sun, Oct 5, 2008 at 2:43 PM, Giel van Schijndel [EMAIL PROTECTED] wrote:
I would prefer to have tools as part of the code/ directory, since
they are (or should be) closely linked to the rest of the code.
Agreed. I would
Dennis Schridde schreef:
Am Sonntag, 5. Oktober 2008 14:43:40 schrieb Giel van Schijndel:
Thus I suggest we use this directory layout for our own repository:
trunk/data
trunk/pkg
Why put pkg here?
pkg will need to be have access to both the source and data...
--
Giel
signature.asc
Per Inge Mathisen schreef:
On Sun, Oct 5, 2008 at 2:43 PM, Giel van Schijndel [EMAIL PROTECTED] wrote:
I would prefer to have tools as part of the code/ directory, since
they are (or should be) closely linked to the rest of the code.
Agreed. I would also prefer to use source instead of code.
Christian Ohm schreef:
On Sunday, 5 October 2008 at 1:50, bugs buggy wrote:
With the upcoming release of the FMV patch in trunk, *before* we add the
fmvs into the repo, I would like to confirm the data structure.
Question: Why do you want to add those to SVN? I can understand the rest of
BTW - what will happen to existing, checked out working copies if the
current contents of trunk/ is moved?
I don't want my existing working copies to die a sudden death.
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
Per Inge Mathisen schreef:
BTW - what will happen to existing, checked out working copies if the
current contents of trunk/ is moved?
I don't want my existing working copies to die a sudden death.
If you have any changes you in any of the directories (subdirectories
included) that will be
On 9/25/08, bugs buggy [EMAIL PROTECTED] wrote:
On 9/23/08, Per Inge Mathisen [EMAIL PROTECTED][EMAIL PROTECTED]
wrote:
One idea: How about using just one repository, but shaped like this:
trunk/
branches/
tags/
then a next level (example from inside trunk):
trunk/code/
trunk/data/
On 9/23/08, Per Inge Mathisen [EMAIL PROTECTED] wrote:
One idea: How about using just one repository, but shaped like this:
trunk/
branches/
tags/
then a next level (example from inside trunk):
trunk/code/
trunk/data/
trunk/originals/
so if you wanted to download the latest of all,
Am Dienstag, 23. September 2008 06:08:37 schrieb bugs buggy:
I was thinking it might be a good time to either split the repository into
dedicated sections, or have multiple repositories.
Can someone state the pros and cons for that? (esp. the pros...) What led to
that idea?
One should be only
Am Dienstag, 23. September 2008 12:00:18 schrieb Freddie Witherden:
Hi Dennis,
Hello Fred and the rest of the Warzone 2100 Resurrection Project!
On 23 Sep 2008, at 08:28, Dennis Schridde wrote:
Am Dienstag, 23. September 2008 06:08:37 schrieb bugs buggy:
I was thinking it might be a good
Hello WZRP, hello Per!
Am Dienstag, 23. September 2008 13:05:58 schrieb Per Inge Mathisen:
One idea: How about using just one repository, but shaped like this:
trunk/
branches/
tags/
then a next level (example from inside trunk):
trunk/code/
trunk/data/
trunk/originals/
so if you
Am Dienstag, den 23.09.2008, 14:51 +0200 schrieb Dennis Schridde:
Hello WZRP, hello Per!
Am Dienstag, 23. September 2008 13:05:58 schrieb Per Inge Mathisen:
One idea: How about using just one repository, but shaped like this:
trunk/
branches/
tags/
then a next level (example
I was thinking it might be a good time to either split the repository into
dedicated sections, or have multiple repositories.
One should be only used for source, and the other only for data.
The question remains, do we stick with GNA, even though they still are
having some issue? Is having
22 matches
Mail list logo
