And did you really intend to refer specifically to Snippets? That doesn't seem like the right place for version control anyway. Code Catacombs, maybe, but in that section I'd prefer to leave code revisions up to the node authors only.

More often that not, a post in Code Catacombs is a request for comment, to initiate a dialog about technique and the relative merits possible alternatives. Personally, I would not be interested in posting alternative versions of other people's code, thereby creating new branches in the source tree for a given module or app. But I pay close attention to the commentary by others, and sometimes I post a suggestion or two, or a (hopefully) helpful reaction for the OP. It's up to the original author when and whether to modify the OP code, and I think that's the right way.

Your idea does raise an important point that sets Code Catacombs apart from other sections -- and it might be worthwhile to extend the node template for this section so it provides a more regimented treatment of OP updates.

As it is, the standard thread in Code has a "heading" field in grey (Category, Author, Description), then the code. After that are the standard reply nodes by others. What would be nice is a separate "grey field", perhaps at the end of the OP (after the code), that provides a list of updates by the OP author.

The point would be that any time authors decide to update their code, a line is added to this extra grey section to keep a public record of the each update (particularly, when it happened), and give the authors a chance to provide a summary of the update's purpose, and even to list version numbers when they want to.

This would make it possible and easy for readers to see whether the author has made changes in reponse to comments by others, by making it easy for the OP author to cite things like "fixed sub foo in response to So-and-so's comments", etc. Also, if I download and use a Code post, then find a problem with it a couple months later, I could revisit the OP and I might see whether the author already fixed it. If not, I could send a bug report as a reply node, and from that point on, comparing the replies (and their dates) to the update record in the OP would make it clear whether the bug ever got fixed by the author.

I suspect this would mean a change in the underlying database table, as well as a slight adjustment to the node template for the Code section, but I think the benefit would make it worthwhile.

The flow of sourceforge is 'register as a user', 'file for a new project', and then 'upload files'.

The flow of my idea is that snippets(or just any code) are automatically pushed into the source tree(and you may say it becomes a project). The original author is the project manager, and he can give permissions to others as co-contributors and they can commit to the main branch. Users who are not co-contributors still can create their own local branches. And all changes are visible to the public.

My idea would be more flexible than sourceforge thing. Codes are created everyday and it's sometimes to heavy to call them real projects. Why not just build a big perlmonk contribution tree and let people check out and check in?

This project can also be isolated from perlmonks and built as an independent one. It just needs to mirror the codes and push them into the tree.

Thanks

Go for it!

If you're going to build something like this, please just add code from authors who've opted in.

I've just written up my perlmonk mirroring script. That's available at here .

A source tree can be built from this, but I don't know how to manage different permissions with one tree(I'm gonna adopt SVN for my purpose). Anyone has ideas?

Thank you.