Talk:Repository Organization
From Museon Softcode Package
One thing I want to suggest is that if we're storing code in a repository? We store it all in pretty/unformatted code. If we're using tools like SVN w/ diffs and all such things, not having everything be one huge chunk of raw text would be highly beneficial. We can then track the diff's and /see/ what people are doing. I actually have a somewhat enhanced/magic unformatter written in Python that includes a bit of a preprocessor and defines/specialized variables, and we could just run it (or any other unformatter, really) over the code to prepare for a "release". Ixokai 02:23, 23 October 2007 (EDT)
As for actual organization, I do think keeping a branch is a good idea, I'd go with:
- /softcode
- cmd
- finger-1
- trunk
- release
- branch
- finger-2
- trunk
- release
- branch
- who
- trunk
- release
- branch
- finger-1
- lib
- ui
- trunk
- release
- branch
- ui
- data
- chargen
- wod1
- wod2
- chargen
- cmd
- /system
- installer
- trunk
- release
- branch
- unformatter
- trunk
- release
- branch
- ...
- installer
- /tags
Basically, I'd suggest dividing the main repository into two groups; code and system. Code is for the Museon modules and code themselves, divided into primarily commands and support libraries. System is for utilities and support code for the Museon project itself; basically its "infrastructure" we develop that isn't installed onto a MUSH as much as its 'meta' code for using and developing Museon.
I'd suggest we don't need a per-item tag; tags are just branches, after all. If someone needs a persistent tag, they can make one like /tags/softcode-cmd-finger-1-tagname. Keeping all tags in a single place is easy, especially if we want to tag the entire repository. E.g., /tags/softcode-Museon-v1.0
-- Ixokai 02:40, 23 October 2007 (EDT)
I'm not sure that I like this. For example, there will be command relating to the UI stuff. Maybe not many, but some. I'd rather break it up by basesystem (including the UI, configuration commmands, base libraries), module1, module2, module2. If, as part of the development, we want to break up stuff we could break up the base system into several files for easier editing and testing. Then when prepping a release we'd combine all the files for a single file for the basesystem installer. I think it makes sense to break up the modules for several reason. One, they are meant to be parts that are independent of the whole. Two, we will hopefully get modules from non-Museon coders. Three, it lets someone checkout a specific module/branch only to edit that rather than checkout and commit the whole project. Grey 23:40, 24 October 2007 (EDT)
- That's sort of how I meant it, actually; I just wasn't thinking. I meant "Cmd" more as "systems", "lib" more as "library modules". Calling it all just "modules" and having them all under that level would work. But I still think a branch/trunk/release under each module would be necessary (I'm dubious on /tags being used outside of global tags, but), and that a 'museon code' vs 'museon infrastructure' division high up'd be necessary. Ixokai 19:42, 25 October 2007 (EDT)
- I shudder and cry at 'formatted' code. If'n you have to do it, fine. Just...I can't work with it. I've tried, and failed. Clotho 09:35, 23 October 2007 (EDT)
- I kinda can't work with regular :( At least once a chunk gets over a certain size (4 lines on an 80 char screen) if its not written by me or something I'm personally deeply familiar with. I really mean storing 'pretty' or 'formatted', just storing, not using anywhere else.. like
&cmd.finger finger-object=$+finger *:
@swi [t(setr(t,pmatch(%0)))]=
0*,{
@pemit %#=[ansi(hr,SYS)]: I can't find %0.
},
{
@pemit %#=[ui-header(+Finger for [name(%qt)])]%RFull name: [xget(%qt,fullname)] ... etc
}
- ... etc? You can't work with that? I mean, we don't have to. Just storing it w/o whitespace makes diffs slightly useless (or at least incredibly hard to use), and diffs with a lot of people working on something in a repo are very important. The ability to check a changeset and go all 'wtf did he do?' and easily/immediately know.
- I can, yes. It takes me three or four times as long to decode and format it properly (that is, into a way for the MU* to take it), and then I can follow it, but it's not a fun thing, especially when it comes to longer code. What you want isn't any more pretty then MU*code, in the end. At least to me. Because I've trained myself to be able to read pure MU*code. Obviously, if I'm overruled, then fine, we can use it, though I don't talk in 'formated' code. Clotho 10:47, 23 October 2007 (EDT)
- When writing formated softcode, you use a utility to quickly remove the formatting and convert it back to uploadable code. The unformatting process (removing line breaks and spaces) should take a few seconds and no more. Ixokai has a utility for it, I use a perl script from Adam Dray on linux and I know either SimpleMU or MUSHclient has this functionality. Grey 23:29, 24 October 2007 (EDT)
- I can, yes. It takes me three or four times as long to decode and format it properly (that is, into a way for the MU* to take it), and then I can follow it, but it's not a fun thing, especially when it comes to longer code. What you want isn't any more pretty then MU*code, in the end. At least to me. Because I've trained myself to be able to read pure MU*code. Obviously, if I'm overruled, then fine, we can use it, though I don't talk in 'formated' code. Clotho 10:47, 23 October 2007 (EDT)
- Personally, I support formatted code. Well formatted code is less prone to missing brackets and unclosed functions, and its way easier to read. Also, as Ixo mentioned the 'diff' utilities used with code repositories will note changed lines. If you edit a piece of code to change a bracket when the line (a line as in a line until there is a carriage return even if the line wraps) of code that is 10 lines wrong then the diff is useless. It returns that huge block of code meaning you need to read it all. On the flip side I am worried that asking people to write formatted code may result in coders just walking away instead of doing it. Grey 23:29, 24 October 2007 (EDT)
- Which is where I am, right now. -I-, personally, have a hell of a time reading 'formatted' code. It's incredibly hard for me to do read it (which destroys your assertion that it's easy to read; it's easy for -you- to read it, not for everyone). Which means I really don't want to have to do it. I do understand that different people have different tastes, but for a project like this, you should be pandering to the lowest common denominator. Which means unformatted code (Or, you could always have both; which would be my vote, if you really want formatted code).
- The thing is, for anything beyond the simpliest of code, I can't read unformatted. I can't tell you how often I've rewritten entire systems from scratch because following someone elses code and in the Big Chunk Of Goop is just so painful I can't keep track of it. It might have to do with the fact that I'm used to whitespace because I'm a programmer during the day job, and the hell of dealing with people who don't follow basic stylistic conventions and then tracking logical flow is a huge pain. In a project like this, we should be pandering to what makes multiple people able to work on the same code with the greatest efficiency. By using formatted code, you can make a small change in a command, and everyone on the mailing list can immediately look at the diff and see -exactly- what you did; it highlights and shows you just that. If its stored unformatted, then there's no way to realistically show exactly what was changed as clearly. So everyone has to read over the entire chunk and then look at the previous chunk and -- it doesn't seem very sustainable of a work model.
- How about this? I have a utility-- there's many out there actually, but I have a cross-platform python script-- that will take "formatted" code code and translate it into "normal mushcode" ... I also have a utility to do the inverse. The inverse isn't perfect, but if I play with it and make it better... would it be an undue burden on you to run the code through the unformatter to quickly and instantly turn it into Standard Blob of Goop? And then when done before committing to the repository, run the inverse? Ideally on an attribute by attribute basis.
- Argh. You didn't understand what I meant. I meant that if youhave to have your formatted code, to have unformatted code as well, if you want to pander to the most people. Like me. I'll gladly toss code I do into your formatter and make it into an unreadable mess, but don't look to me to actually understand what it's trying to do. I'm a simple person, who doesn't like to complicate her life. (Also, if a bit of code you're doing is getting that big, start breaking it into ufuns. ;P)
- I understood perfectly what you meant; I don't see how maintaining a formatted and unformatted version of the code is actually practical. How will we know, for example, that one or the other will not get out of sync? It's trivial to go from "formatted" -> "unformatted" if someone wanted to look at the "unreadable mess" in its natural form. The reverse before committing should be achievable with a program. Ixokai 14:39, 26 October 2007 (EDT)
- Yeah, see, now -I- have to do two extras steps because you can't take the time to learn to read raw MU*code, and -you- can't bother to have to do that yourself? Thanks, but no thanks. I have better things to do with my time, and my desire to help with this project has diminished to zero if I will be forced to meet your specific requirements to submit code. Clotho 09:12, 27 October 2007 (EDT)
- Let's calm down. We're talking about options and no one has yet decided on on method or another. If simply talking about options is going to diminish your interest, then I'm not sure what to say. To do this right, we need these discussions. Formatted code in any language has a ton of benefits -- that's a fact. I personally believe that coders should take some time to learn it, because it is a benefit. However, I also understand that MUSH coding is a hobby and the coders are often more interested in getting something working than necessarily learning everything they can. IE, if you don't need munge() then you don't learn it.
- Yeah, see, now -I- have to do two extras steps because you can't take the time to learn to read raw MU*code, and -you- can't bother to have to do that yourself? Thanks, but no thanks. I have better things to do with my time, and my desire to help with this project has diminished to zero if I will be forced to meet your specific requirements to submit code. Clotho 09:12, 27 October 2007 (EDT)
- I understood perfectly what you meant; I don't see how maintaining a formatted and unformatted version of the code is actually practical. How will we know, for example, that one or the other will not get out of sync? It's trivial to go from "formatted" -> "unformatted" if someone wanted to look at the "unreadable mess" in its natural form. The reverse before committing should be achievable with a program. Ixokai 14:39, 26 October 2007 (EDT)
- Argh. You didn't understand what I meant. I meant that if youhave to have your formatted code, to have unformatted code as well, if you want to pander to the most people. Like me. I'll gladly toss code I do into your formatter and make it into an unreadable mess, but don't look to me to actually understand what it's trying to do. I'm a simple person, who doesn't like to complicate her life. (Also, if a bit of code you're doing is getting that big, start breaking it into ufuns. ;P)
- Which is where I am, right now. -I-, personally, have a hell of a time reading 'formatted' code. It's incredibly hard for me to do read it (which destroys your assertion that it's easy to read; it's easy for -you- to read it, not for everyone). Which means I really don't want to have to do it. I do understand that different people have different tastes, but for a project like this, you should be pandering to the lowest common denominator. Which means unformatted code (Or, you could always have both; which would be my vote, if you really want formatted code).
- ... etc? You can't work with that? I mean, we don't have to. Just storing it w/o whitespace makes diffs slightly useless (or at least incredibly hard to use), and diffs with a lot of people working on something in a repo are very important. The ability to check a changeset and go all 'wtf did he do?' and easily/immediately know.
Now, with all that said I will again say that I prefer formatted code. However, I know that many, and possibly a vast majority of coders either do not prefer or haven't learned to work with it. Ergo, while formatted code provides many benefits (and, no, breaking code into ufuns doesn't address the benfits of formatted code though it does help out some) I am unconvinced it is the best option for Museon.
Lastly, I will say this. Museon is approaching softcode coding like coding is done in 'real' projects. That means proper issue tracking, softcode repositories to both store code and to track changes, and so on. Museon will add more steps than we use in coding for a specific game. Those steps will be in place to let many people work with the project and to see needs doing and what has been done. Yes, these involves a little more work but it is work that will increase the quality of the project, and a solid, high quality project is one of our goals. Grey 21:53, 27 October 2007 (EDT)
- (Ix) I have to make something clear, here: This isn't about trying to burden someone with extra work, and this isn't about me not being able to bother to learn to read unformatted MUSHCode. I can, and have done so; but what I can't do is do so efficiently -- and neither can you. No one can. It's not about writing code, but maintaining code, and maintaining an environment where multiple people are working on the same code or nearby code. For example, if I see a commit, I'm going to look at the diff from the previous version to the new version, and look at each line at least with a more then idle glance; I'm going to review every change. Even if-- and more importantly if-- it's a small change to a command here or there. Review is some of the most important work done in a software project. No matter how good someone codes, and how much they test personally, bugs will get through. A bug on one game is one thing; a bug on a whole host of games that may have a privilege escalation issue, is a whole other.
- (Ix cont) If the code is stored in the repository as unformatted, natural code, then it makes the possibility of efficiently reviewing code effectively impossible. Or at least prohibitively difficult. At work, I spent a significant minority of my time each day reviewing commits by other people; the result is that I find bugs, or more efficient ways to do things, and suggest them and the product's overall quality improves; with unformatted, I maintain there's no way to do active review and the project would suffer. The only kind of review that could happen would be if someone sits with an attribute or command and just goes over it character by character, line by line; instead of looking just at what's changed. That's what's lost-- and that's a significant loss.
- (Ix cont) Finally, please don't take my position or stance as offensive. It's not an attack on you; I"m not trying to burden you or make life all that worse for you. I made a suggestion, and asked if me putting a rather significant amount of effort into a "prettifyer" tool (that's a pain in the ass to write for MUSHCode) would help alleviate your issue. If it doesn't? That's all you have to say. This isn't personal.
- And I'm done repeating myself, over and over again. I CAN'T READ IT. I've tried, I failed to do so in anything approaching a decent time (and I only succeeded, because I took the time to change the format from the unreadable string bean approach, to raw MU*code). I can't write in it, either, which brings me back to my point. That I have to keep stating, apparently. I can't read it. This is a hobby for me, and I have taught myself how to read raw MU*code. Your stating that it is more efficient is flawed. Not everyone is a paid programmer, and most have no idea how to work with your formatted code. Clotho 11:01, 28 October 2007 (EDT)
- edited to add) Which means that if I can't read it, there are others that can't read it. Bah early morning not helping me be clear. The point of saying all of that, is that you're adding addition steps for me to do anything, because I would have to download the code, unformat from your mess, into a version that I can read (and so, for those like me, it would be the same). This is a hobby of mine, and I would like to be able to enjoy it, without having to go through a bunch of steps simply so I can read something to see if there are any bugs in it. Which does mean that if you do what Ix is suggesting, this project would suffer, as you would only have those that can read and like formatted participating. And yes, this discussion has sucked most of my desire to help with this project away. Clotho 11:21, 28 October 2007 (EDT)
