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
<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
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/
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
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
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