From: Stephen C. <sj...@br...> - 2003-05-13 00:39:58
|
Good point. If you have noticed, I have been spending a lot of time recently making sure sheets plays nicely with files on disk. It now is much more conservative about exporting (it will only export a java file if it has been modified... and rather than exporting to mark a file as dirty, it simply touches the file on disk). I really want to get started on doing some true versioning in Sheets. This is the ultimate goal of the project, and it will be the main differentiator in the long run. However, the same problem with filesystems exists for version control systems. Once I build a new version control system into sheets, it needs to be compatible with CVS to be widely adopted. I like your idea about storing meta information in the java files to preserve a round trip import/export. That might also be a good way to bridge the gap between CVS and the SVS (Sheets Versioning System). Following the principle of least astonishment, I'd like the export format to stay roughly the same unless the user makes a change in Sheets. For instance, if you import stuff and leave it on the default sheet, there is no need to export extra information in the Java file about the location of the methods. However, if you did a Sheets-ism like moving a few classes onto the same Sheet, or renaming the Sheet to something more meaningful, then it should export that information into the java file. I forgot to mention, I finished another project this weekend. Cassandra was born on Friday, and came home with mommy from the hospital yesterday. I attached a picture of her to this e-mail. I am taking a few weeks off to take care for mom and baby, but it looks like I may get some quality programming time while they are sleeping (like now). Cheers, --Steve ----- Original Message ----- From: "Aaron Powers" <ap...@cm...> To: <she...@li...> Sent: Monday, May 12, 2003 4:30 PM Subject: [Sheets-devel] A big Sheets idea > Here's an idea I've been thinking about for a while. > > One problem with using sheets with other developers is that we Sheets > developers really want to use Sheets dump files, because it's such a > rich format -- it saves all the hierarchies of files, fragments, etc., > puts in separators, and all sorts of neat stuff. But other developers > who don't use sheets just won't develop on a project at all if we use > dump files as our official, CVS-checked-in format*. One argument to use > dump files anyway is that would encourage more developers to switch to > sheets. But that's a Microsoft-monopoly argument -- there's so many > development environments and some programmers are so entrenched, they > really won't want to switch. > > So what if we make sheets work well without dump files? There's a way > to do this -- here's a couple tricks: > 1) Get rid of the exports list for a class and export in the order users > have organized their fragments. > 2) Turn separators into /* > ---------------------------------------------------------- */ and parse > them back out into separators when they come back in > 3) Use comments to show where fragments go in the hierarchy of sheets -- > at the beginning of a fragment, show a /* This Method's hierarchy: > Project Sheets -> Util Package -> CollectionUtils -> Collection Utils > Mouse Listener Stuff */ > (I only made up the last sheet name -- otherwise it's a real hierarchy) > This makes it human-readable and I think it has all the info that's in > Sheets dump files. > There's also a bug you mentioned with dump files that CVS and diffs > eventually work poorly on large ones -- I dunno if you fixed that, but > it wouldn't be a problem if something like this happened. Of course, > CVS merges would be harder because people can move methods around, but > that's just where CVS starts failing, not Sheets. > > I think this might be the way Sheets should evolve. Of course, it's a > tremendously large leap and requires a ton of changes to the code. > > * Of course, sheets dump files are just fine for the Sheets repository > where people are working on sheets > > - Aaron > > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com > > _______________________________________________ > Sheets-devel mailing list > She...@li... > https://lists.sourceforge.net/lists/listinfo/sheets-devel > |