glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [glob2-devel] mercurial switch


From: Kai Antweiler
Subject: Re: [glob2-devel] mercurial switch
Date: Thu, 19 Apr 2007 09:03:58 +0200
User-agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (linux)

> The problem with Savannah is just exactly that. Its simple enough to do
> that. So anyone could delete all the files. Where as puting them in
> Murcurial, no one would have to reupload them, just go back to a previous
> revision.

Either this would taint the repository for ever, or we would have to
rewrite it.  And if someone pulls the repository before we can rewrite
the history, his repository will have the changes.  And in his next
commit the changes will go into the remote repository again.

It is not as in cvs where each one only stores the latest revision
(and some minor information).  Everyone gets the whole repository.
(Probably this includes every branch in the repository as well.)


A problem with Savannah is that people seem to be reluctant to ask for
permissions, because they are "only" translating or desinging.
Seperating the development should help, even if translators still
would have full write access on the code.


> Mercurial might be the better way to go.
>
> Do you mean remove the binary data part of the repository history?
>> I don't know if that is easy.
>
>
> The only problem with binaryies are they cant see changes in the revisions.
> they can upload anbd download to and from repositories with no problem.

I know there are no problems to add them to the repository.
The problem might be getting them removed from the repository.
No the "binary" trait is the problem just the size.


> But I dislike it for it's mostly different development done
>> by different people the then source coders.  And in our case
>> making the repositories unneccessary large.
>

> The files are only 20mb. And would only be changed once every month if at
> all. Anyone with anything to contribute would have to post on the mailing
> list before putting them in, and so one of the devs can just take that and
> upload it themselves. So contributor access wouldn't be a problem.

If someone redoes the graphics in the future the repository will
fill up half the space that Steph is willing to give us.


> Also there can be an alternative graphics repository.
>
>
> True, but where?

I thought about Stephs server.  If they turn out bad or get stuck
in the development it is easy to remove them or to store them elsewhere.


> We also could try to mix this.
>> If a graphic has no special effect on the code, it will be developed
>> in a separate overlay repository.  Or maybe we can use patch queues for
>> this.  I don't know much about them.
>
>
> Far too complicated. Keep it simple. Put them in Murcurial for testing, then
> later, if the bandwidth is too much, move them elsewhere.

Bandwidth wouldn't be a problem, except for the getting the repository
the first time.  Space would be the problem.

-- 
Kai Antweiler




reply via email to

[Prev in Thread] Current Thread [Next in Thread]