Hey guys, I've been just floating for a while. A long time ago I was interested in using darcs or in the least it's patch theory as part of a package manager I was going to work on (didn't have the time in the end).
I wanted to chose darcs because it sorts out the most conflicts, and through adding custom patch types such as for xorg.conf and different files or types of files in /etc , it could sort these conflicts out automatically. Possibly the most important thing for this would be finding some simpler way to develop and use these patch types. I'm not following the discussion too well. > ... and then there is the fun that David Roundy liked to point out: how > many of us program in complete compilable (and thus > deconstructable/reconstructable) code *all the time*? What if you want > to save a non-working fragment in progress? What if you make a tiny > mistake and the file fails to parse correctly? But, in this case couldn't darcs reverting to its current behavior? The state of the repository could be like: patch A we have this function that function blah patch B more of the same patch C oh no we can't parse it like that no more but well we have this DIFF now. On Wed, Jan 21, 2009 at 6:14 AM, Trent W. Buck <[email protected]> wrote: > On Wed, Jan 21, 2009 at 05:55:21AM +0000, Ganesh Sittampalam wrote: >> On Tue, 20 Jan 2009, Max Battcher wrote: >> >>> Trent W. Buck wrote: >>>> Kari Hoijarvi <[email protected]> writes: >>>> >>>>> Dan Pascu wrote: >>>>> Program is stored as a tree, and the IDE pretty prints it, the way you >>>>> choose to. >>>> >>>> To handle arbitrary source formats in this way (which is what Darcs >>>> would need to do), you need two steps: >>>> >>>> - a READ procedure, which converts the working tree into a normal >>>> form. For example, a C language READ might utilize gccxml, and a >>>> ReStructured Text READ would use rst2xml. >>>> >>>> - a SHOW procedure, which converts the internal representation (normal >>>> form) to something the user can edit without going insane. >>>> >>> ... and then there is the fun that David Roundy liked to point out: how >>> many of us program in complete compilable (and thus >>> deconstructable/reconstructable) code *all the time*? What if you want >>> to save a non-working fragment in progress? What if you make a tiny >>> mistake and the file fails to parse correctly? >>> >>> You need either extremely hardened parsers that can withstand and >>> well recover from error... or separate patch types/source control >>> systems for works in progress versus tested/compiled files... >> >> Or a structure editor, like intentional programming had, in which >> all your works in progress are valid syntax trees (there was a >> special syntactic element for "unfilled in bit", but things like >> brackets did match around it in the rendering). > > That would mean that *everyone* involved in the project has to use a > structure editor. IME there is very little that people will fight for > MORE than the right to use their preferred editor :-) > _______________________________________________ > darcs-users mailing list > [email protected] > http://lists.osuosl.org/mailman/listinfo/darcs-users > -- Declan Naughton _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
