A recent commit to core broke a lot of 4.7 contrib modules [1]. I wanted to patch all contrib modules automatically to save authors the effort of making this change individually. The plan was to take all 4.7 tagged modules, apply the change, then apply the same diff to HEAD. However, of the 74 files in HEAD which might need the change, only 16 are present in 4.7. And I know from looking through those 74 files that there are plenty more that are 4.7 compatible (or at least intend to be). So I revisited Dries' list of the Top 20 most downloaded projects from a couple months ago [2]. The results are simply shocking. Of the 12 modules on the list, only 3 are available for 4.7. The top 3 modules all appear to have 4.7 versions in HEAD, and none of them are tagged properly. This has to change immediately. If Drupal 4.7.0 were to be released now (which would be true if it weren't for some late-reported issues), there would be a riot for all the modules that did not have clear 4.7 versions. And as my situation shows, it is a huge bother for all developers too. The tagging docs are still at: http://drupal.org/node/17570 It takes at most a minute to do. Do so now. Steven Wittens [1] http://drupal.org/node/5371 [2] http://drupal.org/node/25704
While performing the tablesort_pager() removal on 4.7, I ran into several modules which were not branched, but tagged (click, indexpage, views). Please pay attention not to forget the -b parameter when tagging (if you use a GUI, use the 'branch' and not 'tag' command). It is a huge hassle to fix this error, especially on a multi-directory beast like views. Steven Wittens
Steven Wittens wrote:
While performing the tablesort_pager() removal on 4.7, I ran into several modules which were not branched, but tagged (click, indexpage, views). Please pay attention not to forget the -b parameter when tagging (if you use a GUI, use the 'branch' and not 'tag' command). It is a huge hassle to fix this error, especially on a multi-directory beast like views.
Steven Wittens It's not an error, it's intentional on my part. Now you've fucked *me* up.
If you don't like my repository, that's fine. But I do not appreciate you branching it when I was not ready for it it to be branched.
Earl Miles wrote:
Steven Wittens wrote:
While performing the tablesort_pager() removal on 4.7, I ran into several modules which were not branched, but tagged (click, indexpage, views). Please pay attention not to forget the -b parameter when tagging (if you use a GUI, use the 'branch' and not 'tag' command). It is a huge hassle to fix this error, especially on a multi-directory beast like views.
Steven Wittens
It's not an error, it's intentional on my part. Now you've fucked *me* up.
If you don't like my repository, that's fine. But I do not appreciate you branching it when I was not ready for it it to be branched.
Then why did you tag it? Goba
Gabor Hojtsy wrote:
It's not an error, it's intentional on my part. Now you've fucked *me* up.
If you don't like my repository, that's fine. But I do not appreciate you branching it when I was not ready for it it to be branched.
Then why did you tag it?
Goba
I tagged it to have a pointer to a stable version that people can use. It's a bit like how the betas are being done, only there isn't a tag, they just tar one up and put it somewhere. We don't have a lot of flexibility in the system. If I branch the code, I now have to deal with putting fixes into two different places. Drupal itself hasn't been branched for 4.7 yet. If I work in HEAD, that work isn't going to go into 4.7 unless I take the time and energy to port those to the branch. CVS is a pain in the ass about branches, and I didn't want to deal with that hassle. Thus, I used a tag. When 4.7 was actually stable, branched and released, at that time I planned to branch. Why would I want to branch software for a version that isn't even ready yet? Now, I'm branched. Any changes I make to Views now require a bunch of extra work, because branching can't be undone.
Earl Miles wrote:
I tagged it to have a pointer to a stable version that people can use. It's a bit like how the betas are being done, only there isn't a tag, they just tar one up and put it somewhere. We don't have a lot of flexibility in the system.
Nice idea, but nobody else works like this, so Steven couldn't know this.
Now, I'm branched. Any changes I make to Views now require a bunch of extra work, because branching can't be undone.
You can simply rm the files from the 4.7 branch. Cheers, Gerhard
On Friday 14 April 2006 12:29 am, Earl Miles wrote:
Now, I'm branched. Any changes I make to Views now require a bunch of extra work, because branching can't be undone.
Yes, branching can be undone. I did it recently. I think. http://drupal.org/node/54660#comment-109285 yours, A. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple. http://www.gnosis-usa.com/ Revolutionary Psychology, White Tantrism, Dream Yoga... http://www.masquilier.org/ Condorcet, Approval alternative, better voting methods.
It's not an error, it's intentional on my part. Now you've fucked *me* up.
If you don't like my repository, that's fine. But I do not appreciate you branching it when I was not ready for it it to be branched.
Well sorry, but I would prefer if contrib did not devolve into a tag'n'branch bonanza where everyone has their own practices. It is messy enough in there already. Sticky tags are immensely annoying to deal with from where I'm standing. It is only because of the CVS tag / branch duality that this even works for packaging up the releases. And there is no easy way to check if a sticky tag was applied on purpose (like you did) or by someone who used the wrong cvs command (99% of all cases I encounter). While committing to other people's directories is rare, there are some perfectly good reasons to do it. Sometimes core-wide features, sometimes CVS maintenance (e.g. adding id tags or readmes). I've done this on several occasions (theme search box, ajax autocomplete and now tablesort_pager) and no-one has ever complained. I think we should keep it an option by requiring proper branching for the official Drupal tags. Outside of those, you can do what you want. Steven Wittens
several modules which were not branched, but tagged (click, indexpage, views). Please pay attention not to forget the -b parameter when tagging (if you use a GUI, use the 'branch' and not 'tag' command). It is a huge hassle to fix this error, especially on a multi-directory beast like views.
Click is mine, and indexpage was ported to 4.7 by me. I tried to move the tag, delete the tag, but nothing worked. e.g. for click: $ cvs tag -d DRUPAL-4-7 cvs tag: Untagging . cvs tag: Not removing branch tag `DRUPAL-4-7' from `/cvs/drupal-contrib/contributions/modules/click/README.txt,v'. cvs tag: Not removing branch tag `DRUPAL-4-7' from `/cvs/drupal-contrib/contributions/modules/click/click.module,v'. cvs tag: Not removing branch tag `DRUPAL-4-7' from `/cvs/drupal-contrib/contributions/modules/click/click.mysql,v'. $ cvs tag -dF DRUPAL-4-7 cvs tag: Untagging . cvs tag: Not removing branch tag `DRUPAL-4-7' from `/cvs/drupal-contrib/contributions/modules/click/README.txt,v'. cvs tag: Not removing branch tag `DRUPAL-4-7' from `/cvs/drupal-contrib/contributions/modules/click/click.module,v'. cvs tag: Not removing branch tag `DRUPAL-4-7' from `/cvs/drupal-contrib/contributions/modules/click/click.mysql,v'. $ cvs tag -bF DRUPAL-4-7 cvs tag: Tagging . cvs tag: README.txt: Not moving branch tag `DRUPAL-4-7' from 1.1.2.2 to 1.1.0.4. cvs tag: click.module: Not moving branch tag `DRUPAL-4-7' from 1.3.2.2 to 1.4.0.2. cvs tag: click.mysql: Not moving branch tag `DRUPAL-4-7' from 1.2.2.2 to 1.2.0.4. What can we do?
On Friday 14 April 2006 12:14 am, Khalid B wrote:
What can we do?
http://drupal.org/node/57531#comment-109286 -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple. http://www.gnosis-usa.com/ Revolutionary Psychology, White Tantrism, Dream Yoga... http://www.masquilier.org/ Condorcet, Approval alternative, better voting methods.
On 4/13/06, Anguo <linux-tw@masquilier.org> wrote:
On Friday 14 April 2006 12:14 am, Khalid B wrote:
What can we do?
Tried it. Works. Thanks. To summarize for everyone: cd HEAD/contributions/modules/yourmodule cvs tag -dB DRUPAL-4-7 cvs tag -b DRUPAL-4-7 This effectively moves the tag and branch from whereever it is to the version that is in HEAD now.
On 13 Apr 2006, at 5:24 PM, Steven Wittens wrote:
This has to change immediately. If Drupal 4.7.0 were to be released now (which would be true if it weren't for some late-reported issues), there would be a riot for all the modules that did not have clear 4.7 versions. And as my situation shows, it is a huge bother for all developers too.
This is one of the things I would like to see with a premium repository. If this premium set of modules are not tagged for the next release, they should actually hold up that release. IE: critical bugs. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
I can't shake the feeling that our contributions repository is groaning at the seams and needs some sort of radical re-think. Steven, how can I tell if a module is tagged but not branched? I'm quite possibly guilty of this. What is the remedy? Adrian Rossouw wrote:
On 13 Apr 2006, at 5:24 PM, Steven Wittens wrote:
This has to change immediately. If Drupal 4.7.0 were to be released now (which would be true if it weren't for some late-reported issues), there would be a riot for all the modules that did not have clear 4.7 versions. And as my situation shows, it is a huge bother for all developers too.
This is one of the things I would like to see with a premium repository.
If this premium set of modules are not tagged for the next release, they should actually hold up that release.
IE: critical bugs.
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Robert Douglass wrote:
I can't shake the feeling that our contributions repository is groaning at the seams and needs some sort of radical re-think. Steven, how can I tell if a module is tagged but not branched? I'm quite possibly guilty of this. What is the remedy?
It can be kind of obscure and obtuse. Perhaps the easiest way to see if tags are branches is to use this command: cvs status -v <filename> It will show you the tags and matching branches, if any. Branches always seem to have 3-place version numbers, e.g. x.y.z and revisions within those branches are 4-place version numbers, e.g. x.y.z.u, but unless you know where to look and what to look for, you might not notice them and/or you might be confused as to what is branched where. ..chrisxj
I might add to this that there are a number of 4.6 modules that aren't tagged 4-6 either. Node relativity was one of them and I recently tagged it because eventually I'm going to complete the port to 4.7. The danger here is that if someone starts working on the HEAD version, say to upgrade to 4.7 compatibility, and there isn't a 4-6 tag, then the 4-6 version is all but lost to anyone without rather advanced CVS skills. This is like letting museums and opera houses fall down and rot because nobody bothers to paint them. -Robert Steven Wittens wrote:
A recent commit to core broke a lot of 4.7 contrib modules [1]. I wanted to patch all contrib modules automatically to save authors the effort of making this change individually. The plan was to take all 4.7 tagged modules, apply the change, then apply the same diff to HEAD.
However, of the 74 files in HEAD which might need the change, only 16 are present in 4.7. And I know from looking through those 74 files that there are plenty more that are 4.7 compatible (or at least intend to be).
So I revisited Dries' list of the Top 20 most downloaded projects from a couple months ago [2]. The results are simply shocking. Of the 12 modules on the list, only 3 are available for 4.7. The top 3 modules all appear to have 4.7 versions in HEAD, and none of them are tagged properly.
This has to change immediately. If Drupal 4.7.0 were to be released now (which would be true if it weren't for some late-reported issues), there would be a riot for all the modules that did not have clear 4.7 versions. And as my situation shows, it is a huge bother for all developers too.
The tagging docs are still at: http://drupal.org/node/17570 It takes at most a minute to do. Do so now.
Steven Wittens
[1] http://drupal.org/node/5371 [2] http://drupal.org/node/25704
participants (9)
-
Adrian Rossouw -
Anguo -
Chris Johnson -
Earl Miles -
Gabor Hojtsy -
Gerhard Killesreiter -
Khalid B -
Robert Douglass -
Steven Wittens