We were discussing this for years and the reason this does not exist is that if someone maintains a project through a web interface then it's absolutely impossible to have more than person to maintain. Branching and tagging is a challenge too.

However, the GSoC project that Christopher does, http://drupal.org/project/conflict_resolver can help with merging.

Before doing anything, you need to figure out branching and tagging.

Comments

chx’s picture

Title: Conceptual failure » Branching and tagging

webchick says merge is not an issue as themes are maintained by one person. Good. Then you only have branching and tagging to figure out.

chx’s picture

Make people upload with the release filename: project-6.x-1.0.zip . Help them figure out that name as we now have a helper already on d.o.

chx’s picture

Yes this means one release per upload so what?

webchick’s picture

I think the naming convention is a very sensible approach, at least for v1.0 (or 0.1 or whatever ;)).

Of course, dww will scream bloody murder about it if someone is uploading a new one of these every 5 seconds, but as long as the instructions on the form make it clear that when you do this, everyone using your theme will get screamed at to update and so try and batch bug fixes/features, I think that's fine.

dww’s picture

BLOODY MURDER!!!!

(Couldn't resist). ;)

ceardach’s picture

My concept for branching and tagging would be to do that for them by allowing them to select options on the upload form. The user would have the following options when uploading a file:

  • Drupal Version
  • Major Version

The scripts would then handle figuring out the naming scheme for committing to CVS. Uploads would be committed to the branch of the major version, and allow -dev branches. A separate option (flag? checkbox on node form?) would then run a script to create a tag of the next increment up on the selected branch.

In my past, I have never ever ever had any luck to get people to name files a certain way. I'd like to automate as much as possible.

As for merging, as Webchick clarified, it will not be in the scope of this project. I called this simple_committer because it will never be sophisticated enough to handle everything an application could. The goal is to allow a simplified interface to get them into contributing, and then they can move on to installing and using a GUI application to be their front end.

arhak’s picture

just what I'm looking for
where is the dev snapshot?
I would like to contribute getting this done
is there anything to patch on?

- I agree the naming conventions are hard to enforce, and I would go for the form with major/minor versions
neverthe less, you always can reject the commit as shown in upload2_wrong_version_sequence.png

- I made some screenshots about how the process should be perceived (feedback messages) after uploading the file
new major release
wrong_version_sequence
new minor release
commit to head
commit to head of another major branch
commit to head of another minor branch