proposal: put more files under revision control
John H Palmieri
- the plain text files in SAGE_ROOT: makefile, sage, README.txt,
COPYING.txt, etc.
- the plain text files in SAGE_ROOT/spkg: install, gen_html,
README.txt, standard/deps, etc.
Recently, there has been a lot of work done on spkg/install and spkg/
standards/deps, for example, and it would have been much easier to
manage if they were in a mercurial repo somewhere.
I propose that we place these under revision control. Specifically, I
propose that we should put copies of these files in a directory local/
bin (which is under revision control as the sage_scripts spkg) and
then copy them to the appropriate places in spkg-install. I'm not
sure this is the best approach, but it seemed easier than creating a
new repo just for these files.
The patch at #9433 implements this, and also adds information to the
README.txt files in the appropriate directories explaining revision
control for these files and how to edit them.
Opinions?
--
John
William Stein
> Right now, several important files are not under revision control:
>
> - the plain text files in SAGE_ROOT: makefile, sage, README.txt,
> COPYING.txt, etc.
> - the plain text files in SAGE_ROOT/spkg: install, gen_html,
> README.txt, standard/deps, etc.
>
> Recently, there has been a lot of work done on spkg/install and spkg/
> standards/deps, for example, and it would have been much easier to
> manage if they were in a mercurial repo somewhere.
A big +1 on putting these files under revision control.
>
> I propose that we place these under revision control. Specifically, I
> propose that we should put copies of these files in a directory local/
> bin (which is under revision control as the sage_scripts spkg) and
> then copy them to the appropriate places in spkg-install. I'm not
> sure this is the best approach, but it seemed easier than creating a
> new repo just for these files.
A big -1 on this approach to doing so. It's a hack and will lead to
pain and suffering.
E.g., imagine somebody taking great care modifying spk/standard/deps, only to
have it overwritten by some version in local/bin/.
>
> The patch at #9433 implements this, and also adds information to the
> README.txt files in the appropriate directories explaining revision
> control for these files and how to edit them.
It's too complicated.
Can't we just make SAGE_ROOT an hg repo, and selectively add
everything that needs to be under revision control now, but isn't
already?
-- William
>
> Opinions?
>
> --
> John
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
David Kirkby
> Right now, several important files are not under revision control:
<SNIP>
> I propose that we place these under revision control. Specifically, I
> propose that we should put copies of these files in a directory local/
> bin (which is under revision control as the sage_scripts spkg) and
> then copy them to the appropriate places in spkg-install. I'm not
> sure this is the best approach, but it seemed easier than creating a
> new repo just for these files.
<SNIP>
> Opinions?
>
> --
> John
I agree they should be in a repository.
Like William, I think it is overly complex, and its simply better to
create another repository in $SAGE_ROOT. and add files to that.
I sometimes wonder if it would be better if there was only one
repository for things except .spkg files. Perhaps rather than going
from 2 to 3 repositories, we should go from 2 to 1, and stick
everything in the new $SAGE_ROOT repository. (I suspect one can merge
repositories, so information would not be lost).
Dave
Robert Miller
> repository for things except .spkg files. Perhaps rather than going
> from 2 to 3 repositories, we should go from 2 to 1, and stick
> everything in the new $SAGE_ROOT repository. (I suspect one can merge
> repositories, so information would not be lost).
I would exclude SAGE_ROOT/devel/sage-main from this, for several
reasons. One, it is essentially its own spkg. Two, the vast majority
of Sage developers use this repository and are basically ignorant of
the rest, and changing its location might cause undue confusion. Also,
would every patch on trac need updating after this?
Otherwise I think this is a good idea.
--
Robert L. Miller
http://www.rlmiller.org/
Florent Hivert
On Thu, Jul 08, 2010 at 06:28:32PM +0200, Robert Miller wrote:
> > I sometimes wonder if it would be better if there was only one
> > repository for things except .spkg files. Perhaps rather than going
> > from 2 to 3 repositories, we should go from 2 to 1, and stick
> > everything in the new $SAGE_ROOT repository. (I suspect one can merge
> > repositories, so information would not be lost).
>
> I would exclude SAGE_ROOT/devel/sage-main from this, for several
> reasons. One, it is essentially its own spkg. Two, the vast majority
> of Sage developers use this repository and are basically ignorant of
> the rest, and changing its location might cause undue confusion. Also,
> would every patch on trac need updating after this?
Big +1 to exclude SAGE_ROOT/devel/sage-(main|any other branches) ! Some other
related reasons:
- how do you deals with those branches if you have only one repo ?
- when having different branches (I usually have at least sage-main,
sage-review, sage-combinat) it's important to have different hg repositories
and in particular different hg queues which must be able to exchange
(import/export) patches.
- Also, If you remove the SAGE_ROOT/devel/sage-branch repositories then we
have to rethink the whole architecture for the sage-combinat project and to
rebase a queue of more that 200 patches...
Cheers,
Florent
William Stein
Adding a new repository in SAGE_ROOT, and not getting rid of any
existing repositories is absolutely trivial to implement.
Proposals about getting rid of existing repositories or merging them
are good to think about, but are potentially very, very difficult to
implement. Moreover, even if we *are* going to do that, it could (and should)
be done later after we have a SAGE_ROOT repository.
-- William
John H Palmieri
> Hi,
>
> Adding a new repository in SAGE_ROOT, and not getting rid of any
> existing repositories is absolutely trivial to implement.
create a new hg repository?
Anyway, I've taken a shot: see
<http://trac.sagemath.org/sage_trac/ticket/9433>
--
John
Dr. David Kirkby
> Hi,
>
> Adding a new repository in SAGE_ROOT, and not getting rid of any
> existing repositories is absolutely trivial to implement.
Yes.
> Proposals about getting rid of existing repositories or merging them
> are good to think about, but are potentially very, very difficult to
> implement. Moreover, even if we *are* going to do that, it could (and should)
> be done later after we have a SAGE_ROOT repository.
>
> -- William
Agreed. It would not be a trivial process, but I suspect one could do it. Long
term, it seems a better approach to me.
An obvious direction to take would be to ask on a Mercurial mailing list for
advice on this.
As you say, it is not even worth thinking about until a $SAGE_ROOT repository is
in place.
Dave