On Thu, 2008-06-05 at 16:27 -0700, Carl Witty wrote: > 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 :)
this is the more conventional problem. Generally speaking, getting new code requires compilation... DCVS merely adds another way to "get new code"... but the generation of "derivatives" still needs to happen. So, turns out git supports a "local clone"... but I'll speak to that below... > > > > 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? basically, PyDev sometimes does silly things when creating a project which points to a directory which is a symlink... it uses whatever the actual directory is. The reason this matters is because I'm doing remote debugging... so paths are critical. Turns out I'm in the soup anyway here cuz of the general build issue (code ends up in site-packages), and pydev provides mechanisms to deal with the mapping... So, this is only related in that in screwing around with how to get PyDev to work with multiple remote Sage instances, I came across this mapping issue... which exposed the symlink... fast forward and we're here. > > 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. the symlink is how you change branches... sage -br changes the symlink and then compiles code into the right place based on a path reliant on the symlink. > > 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.) <<< opinion waver applied >>> Well, I'm not pushing git cuz I've used 8 of my 9 lives fighting this one in a couplea other forums... but git allows a "local" clone which means that underneath it links to a single repo. So, you could create sage clones with different branch names (or the same but I'd imagine that would be pointless and badness) but checkins would all be associated with the same local repo. Then, the branches are coordinated with whomever. In Sage, at this point, that probably means with sagemath.org. IMHO, I'd say that Sage is a perfect candidate for git for all the reasons people hate git... all that flexibility is too hard for people who just wanna code. (oh yea, and the docs suck etc...) but in Sage, basically, everything is nailed up under the Sage distro... so any and all kinds of custom wierdness could be incorporated into the Sage "Master Control Program"... we could customize it to our hearts content... and not force anybody to know anything beyond a couplea sage commands which perform the necessary magic. The windows stuff pretty much works... and is gonna be a complete non-issue given the job ahead of mabshoff and crew getting the other things to work on windows. Furthermore, I'm guessing that the flexibility would more than pay for itself. -glenn > > Carl > > > -- Glenn H. Tarbox, PhD || 206-494-0819 || [EMAIL PROTECTED] "Don't worry about people stealing your ideas. If your ideas are any good you'll have to ram them down peoples throats" -- Howard Aiken --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
