On Jun 5, 3:28 pm, "Glenn H Tarbox, PhD" <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-06-05 at 14:23 -0700, Carl Witty wrote:
> > As far as the second half of your response, I'm confused.  The build
> > system already understands chains where the output of one step is the
> > input to the next: the .so file is made from the .o file, which is
> > made from the .c file, which is made from a variety of .pyx, .pxd,
> > and .pxi files.  When we change a .pxi file, all the required
> > rebuilding is done automatically (which may take 10 or 20 minutes for
> > changes to "core" .pxi files, which is why we don't want to do it
> > every time we change branches).
>
> yea, as I said to Robert, the frequent branch toggle is a new one to me.
> Typically, a developer branches, hacks, occasionally shelving, but
> working through to local merge.  Maybe Sage development is different...
> I really don't know.

Hmm... now that you mention it, I hardly ever change branches
(clones), so I'm not sure why this feels so important to me (and
evidently to Robert).  Also, most branch changes would rebuild fairly
quickly (if every modification to Sage required a 20-minute rebuild,
development would be very painful; but it's actually fairly rare to
touch these "core" .pxi files).  My current theory is that it only
takes 2 or 3 20-minute rebuilds on branch changes to leave you scarred
for life, and willing to do almost anything to avoid the pain :)

> > Are you talking about the sage -> sage-<NAME> symlink?  I'm never
> > confused by it because I never use it; I always use sage-<NAME>
> > directly.  We could probably figure out a way to avoid this symlink,
> > if we decided it was a problem.
>
> Yup, Robert brought up the same point...  and its perhaps only a problem
> for me cuz I'm using PyDev which behaves poorly... its my problem and
> will fix it... but it exposed things to me which seem "unnatural" and
> upon further investigation got downright kinky... not that I'm not
> flexible (I did move to Seattle but didn't get all the piercings just
> yet :-)

What does PyDev do with the symlink?

I don't actually know what all the symlink is used for, so I don't
know how hard it would be to eliminate; but I would guess that moving
it somewhere else would not be too bad.

Actually, we presumably can't rely on the symlink for a native Windows
port anyway, so the people working on that may eliminate the symlink
fairly soon.

> OTOH, Sage does all kinds of things differently... and its amazing
> (there's no system out there where you download a 200MB tarball and type
> make... it just doesn't happen) so I'm a bit reluctant to mess around
> all that much just yet...

Yep... it certainly impressed me the first time I installed it.

> > > > 4) It's easier to abandon the history of a clone, both for hopelessly  
> > > > broken development efforts and refereeing of other people's patches.
>
> > > git branch -D badbranch
>
> > > as opposed to the usual
>
> > > git merge developmentBranch
> > > git branch -d developmentBranch
>
> > > (btw, I'm a git user... I'm sure there's something similar in Hg)
>
> > I don't think there is.  (I've looked.)
>
> I'll take your word for it.... but there definitely should be... since
> there isn't I'd posit that there is badness architecturally with Hg cuz
> this issue must come up multiple times a day....

I only know a little bit about mercurial internals, but I know enough
to have a guess as to why this is hard.

In mercurial, each source file has one corresponding file in the
repository; the repository files are treated as append-only.  So if
you make changes to a file in branch A, commit, change it in branch B,
commit, branch A, commit, branch B, commit, then this repository file
will end up with the changes ...ABAB.  Then expunging branch A would
require rebuilding this file, which otherwise is never necessary in
mercurial.  (There is a mercurial extension that lets you eliminate
all changes in a repository after a given revision number; this is
easier to handle, since you just have to go through all the repository
files and truncate them to the appropriate point.)

Carl

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

Reply via email to