I don't exactly understand these distributed control systems very well, so hopefully this isn't an obvious question. Right now as I'm working on symbolics I commonly have files from multiple branches open (symbolics-stable/backup, symbolics-current, calculus-old). I also have to frequently have to toggle between them (to test backwards compatibility). It seems like switching to branching would require having three full sage installs at the cost of a huge amount of space if I want to be able to switch between them quickly and edit multiple versions of the same file, which seems like a massive negative side effect. Do I understand this right?
On Thu, Jun 5, 2008 at 5:27 PM, Carl Witty <[EMAIL PROTECTED]> 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 :) > >> > 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 -~----------~----~----~----~------~----~------~--~---
