[drupal-devel] PHPTemplate hits core ... finally
Some changes: 1. I committed the PHPTemplate engine to core and removed the XTemplate engine from core. 2. I replaced the XTemplate-based version of Bluemarine with the PHPTemplate-based version. 3. I moved the XTemplate engine and the Pushbutton theme to the contributions repository. (For almost 2 years XTemplate has been part of Drupal core.) Some TODO-list items: 1. Figure out the menu configuration. High priority. 2. Add one more PHPTemplate-based theme to core. Medium priority. Thanks Adrian et al, -- Dries Buytaert :: http://www.buytaert.net/
Yes. See my previous post to this list here http://lists.drupal.org/archives/drupal-devel/2005-05/msg00163.html The project page for this theme is here http://drupal.org/node/15059 On 5/4/05, Boris Mann <boris@bryght.com> wrote:
On 4-May-05, at 11:48 AM, Steven Wittens wrote:
Some TODO-list items:
3. Port Pushbutton to PHPTemplate. It's a very good core theme because of its accessibility and should be re-added when ported.
This is done already -- PushbuttonPHP or something like that.
-- Boris
On 5/4/05, Dries Buytaert <dries@buytaert.net> wrote:
1. I committed the PHPTemplate engine to core and removed the XTemplate engine from core.
This change has completely broken primary and secondary links in EVERY non-phptemplate theme. (including chameleon, which is in core) I am working on a patch. Also, there is now a duplicated function (seemingly unrelated) in updates.inc causing a parse error in update.php. -- update_130() is the problem function. It would be nice if someone could come up with some clever regexp's to place in an update function for migrating from the old links structure to the new one.
On 5/4/05, Tom Dobes <tdobes@gmail.com> wrote:
On 5/4/05, Dries Buytaert <dries@buytaert.net> wrote:
1. I committed the PHPTemplate engine to core and removed the XTemplate engine from core.
This change has completely broken primary and secondary links in EVERY non-phptemplate theme. (including chameleon, which is in core)
I am working on a patch.
Done. See http://drupal.org/node/21855
Hello, This is great news, and to make the transition a little easier for people I have posted my "XTemplate to PHPTemplate conversion" howto at drupal.org, See http://drupal.org/node/22019. The main reason that I ported the bluemarine theme that has now been included in core was so that I could create this document. I hope that it is helpful to everyone is going to be converting their XTemplate themes. <cvs rant> Moving the bluemarine PHPTemplate theme into core is one of the main reasons that I am starting to dislike cvs. Because of the move all the history of this is gone, and even the more importantly the credit to me. Also the accountability that this is 100% GPL code is also lost as there is no history before the initial commit. I know that the bluemarine PHPTemplate version is derived work from the original XTemplate version so there is no doubt of it compliance but what about other code. I am not saying that everyone needs commit access into core, but the history and the accountability need to be preserved. </cvs rant> Gordon. -----Original Message----- From: drupal-devel-bounces@drupal.org [mailto:drupal-devel-bounces@drupal.org] On Behalf Of Dries Buytaert Sent: Thursday, 5 May 2005 4:18 AM To: drupal-devel@drupal.org Subject: [drupal-devel] PHPTemplate hits core ... finally Some changes: 1. I committed the PHPTemplate engine to core and removed the XTemplate engine from core. 2. I replaced the XTemplate-based version of Bluemarine with the PHPTemplate-based version. 3. I moved the XTemplate engine and the Pushbutton theme to the contributions repository. (For almost 2 years XTemplate has been part of Drupal core.) Some TODO-list items: 1. Figure out the menu configuration. High priority. 2. Add one more PHPTemplate-based theme to core. Medium priority. Thanks Adrian et al, -- Dries Buytaert :: http://www.buytaert.net/ !DSPAM:4279133129753381880678!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05 May 2005, at 1:35 AM, Gordon Heydon wrote:
<cvs rant>
Darix has showed me some nifty SVN things, and convinced me that we should move Drupal to svn. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCeV79gegMqdGlkasRAphZAKDWjeuxPnebP0vS+8Y/8q6HTUEjoQCgz80Q 4KIKCky6W1CBxqAwxWZcxDs= =GyD2 -----END PGP SIGNATURE-----
Hello, Svn suffers from other issues, and AFAIK the it will not allow commits to other from one person to be applied by another. So in the situation of drupal where we have a few lieutenants that commit patches to core, the commits are marked as coming from them, and not the original person. If you take a distributed source management system like bitkeeper, arch, bazaar, git and others you can have the lieutenants commit the patch to the core, by getting the change set from the original developer's repository or via other means and the history, comments and user data is retained. Gordon. -----Original Message----- From: drupal-devel-bounces@drupal.org [mailto:drupal-devel-bounces@drupal.org] On Behalf Of Adrian Rossouw Sent: Thursday, 5 May 2005 9:47 AM To: drupal-devel@drupal.org Subject: Re: [drupal-devel] PHPTemplate hits core ... finally -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05 May 2005, at 1:35 AM, Gordon Heydon wrote:
<cvs rant>
Darix has showed me some nifty SVN things, and convinced me that we should move Drupal to svn. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCeV79gegMqdGlkasRAphZAKDWjeuxPnebP0vS+8Y/8q6HTUEjoQCgz80Q 4KIKCky6W1CBxqAwxWZcxDs= =GyD2 -----END PGP SIGNATURE----- !DSPAM:4279601e72505005216706!
For what its worth, KDE just switched to Subversion recently. Details here: http://developers.slashdot.org/article.pl?sid=05/05/04/136257&tid=121&tid=15... On 5/4/05, Gordon Heydon <gordon@heydon.com.au> wrote:
Hello,
Svn suffers from other issues, and AFAIK the it will not allow commits to other from one person to be applied by another.
So in the situation of drupal where we have a few lieutenants that commit patches to core, the commits are marked as coming from them, and not the original person.
If you take a distributed source management system like bitkeeper, arch, bazaar, git and others you can have the lieutenants commit the patch to the core, by getting the change set from the original developer's repository or via other means and the history, comments and user data is retained.
Gordon.
-----Original Message----- From: drupal-devel-bounces@drupal.org [mailto:drupal-devel-bounces@drupal.org] On Behalf Of Adrian Rossouw Sent: Thursday, 5 May 2005 9:47 AM To: drupal-devel@drupal.org Subject: Re: [drupal-devel] PHPTemplate hits core ... finally
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05 May 2005, at 1:35 AM, Gordon Heydon wrote:
<cvs rant>
Darix has showed me some nifty SVN things, and convinced me that we should move Drupal to svn.
- -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin)
iD8DBQFCeV79gegMqdGlkasRAphZAKDWjeuxPnebP0vS+8Y/8q6HTUEjoQCgz80Q 4KIKCky6W1CBxqAwxWZcxDs= =GyD2 -----END PGP SIGNATURE-----
!DSPAM:4279601e72505005216706!
On 2005-05-05 10:01:10 +1000, Gordon Heydon wrote:
Svn suffers from other issues, and AFAIK the it will not allow commits to other from one person to be applied by another. svn diff > patch ? you can even do patches with new files in it. (cvs add somefile -> you need write access) So in the situation of drupal where we have a few lieutenants that commit patches to core, the commits are marked as coming from them, and not the original person. how would this differ from other SCM? it is always the maintainer who merges the change, who is mentioned as author. If you take a distributed source management system like bitkeeper, arch, bazaar, git and others you can have the lieutenants commit the patch to the core, by getting the change set from the original developer's repository or via other means and the history, comments and user data is retained. SVN can give you both. centralized repository combined with the power of distributed development. how? svk. as mentioned by chris later in the thread. i currently work on a howto about using svk for drupal development. i hope i can finish it in the next days to show it here. even without svk i think svn would be worth the move. atomic commits. versioned directories. easy tagging, many operations work offline. much friendly UI. ... hope this helps darix
Hello, Marcus Rueckert wrote:
On 2005-05-05 10:01:10 +1000, Gordon Heydon wrote:
Svn suffers from other issues, and AFAIK the it will not allow commits to other from one person to be applied by another.
svn diff > patch ? you can even do patches with new files in it. (cvs add somefile -> you need write access)
No this will mean that the patch will be applies by the submitter. and none of the original details will be keep. Distributed SVM systems allow patches to be applies by another user to the old core repository and retail the entire history, and accountibility.
So in the situation of drupal where we have a few lieutenants that commit patches to core, the commits are marked as coming from them, and not the original person.
how would this differ from other SCM? it is always the maintainer who merges the change, who is mentioned as author.
Yes it is the maintainer, but the changeset is accredited to the original author. See bitkeeper and how Linus worked. He was the only one the could commit to his tree but, credit was given to the orginal user.
If you take a distributed source management system like bitkeeper, arch, bazaar, git and others you can have the lieutenants commit the patch to the core, by getting the change set from the original developer's repository or via other means and the history, comments and user data is retained.
SVN can give you both. centralized repository combined with the power of distributed development. how? svk. as mentioned by chris later in the thread. i currently work on a howto about using svk for drupal development. i hope i can finish it in the next days to show it here. even without svk i think svn would be worth the move. atomic commits. versioned directories. easy tagging, many operations work offline. much friendly UI. ... hope this helps darix
It is not a distributed SVM, it is a centralised and requires access to the server to commit any changes. Gordon.
On 2005-05-06 07:12:03 +1000, Gordon Heydon wrote:
SVN can give you both. centralized repository combined with the power of distributed development. how? svk. as mentioned by chris later in the thread. i currently work on a howto about using svk for drupal development. i hope i can finish it in the next days to show it here. even without svk i think svn would be worth the move. atomic commits. versioned directories. easy tagging, many operations work offline. much friendly UI. ... hope this helps darix
It is not a distributed SVM, it is a centralised and requires access to the server to commit any changes.
thats not true. any developer can network his svk repository. so developers can merge changes from each other. the easiest way to do so: $ svnserve -d -r $HOME/.svk/local and people can use the local branch. darix
Hello, I have been debating this with darix a few times already, but: 1) moving from CVS to SVN must be done when the majority is ready for that. We should thus 1.1) investigate if there are people not at all ready for a move 1.2) investigat who will help with the move. it should never be only on the shoulders of those few who already have a lot on their shoulders (i.e. Dries, kjartan and Steven). 2) If ever we move, we should do it good. Thus look for ALL alternatives, not just look at SVN, because its the closest at hand. IMO SVN is nothing more then a revised CVS. The real problems are not solved, only made a little easier to deal with. SVN continues on a road that, IMO, is not the perfect road for Open source collaboration. The fact that Drupal developement is very much decentralised, non hierarchical and above all voluntary, should be reflected by the RCS we choose to use. SVN gets closer then CVS, but IMO (by far) not close enough. Again, i see it as a slightly improved CVS. but nothing more. I have been looking around, and read about DARCS (http://abridgegame.org/darcs/) A system that is build purely with decentralized, vuluntary, non-hierarchical communities in mind. IMO it gets much closer to our ideal workflow then SVN will ever get us. And yes, I know its easy to sort-of emulate darcs at the client side, while using SVN on the server, but that does not solve the whole idea of SVN simply not being suited enough for Drupals structure and comm. (/. http://it.slashdot.org/it/04/11/25/0136249.shtml?tid=156&tid=218) O, and afaik darcs is about the easiest to learn from the oss RCSs. (http://zooko.com/revision_control_quick_ref.html) But that does not mean we should go for darcs, just now. I simply try to point out we should look at all options, not just choose one, 'cause its been chosen a lot, and thus is the first at hand. We should research, and then choose the best for our system. Ber
On 06 May 2005, at 19:54, Ber Kessels wrote:
I have been looking around, and read about DARCS (http://abridgegame.org/darcs/) A system that is build purely with decentralized, vuluntary, non-hierarchical communities in mind. IMO it gets much closer to our ideal workflow then SVN will ever get us.
I've been using Darcs for 2-3 months now. Based upon my experience, I would advise against using Darcs: 1. You need to master more commands. It's slightly more complex than CVS. 2. If you delete files from your tree, there is no equivalent to 'cvs -q up -AdP' to get them back. Highly annoying. 3. It is not scalable due to the fact it is written in Haskell. I'm more interested in 'git', but it might be premature. -- Dries Buytaert :: http://www.buytaert.net/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06 May 2005, at 8:20 PM, Dries Buytaert wrote:
On 06 May 2005, at 19:54, Ber Kessels wrote:
I have been looking around, and read about DARCS (http://abridgegame.org/darcs/) A system that is build purely with decentralized, vuluntary, non-hierarchical communities in mind. IMO it gets much closer to our ideal workflow then SVN will ever get us.
I've been using Darcs for 2-3 months now. Based upon my experience, I would advise against using Darcs:
Also, one of the benefits of SVN is that it's already reached 1.0 , and there are many gui tools available for it. Anyone know the benefits of GNU Arch? - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCe8GwgegMqdGlkasRAl3qAJ0R0DIIw0TQT+re25GFk9cTtqVaWQCfeWZ+ 2YCwrj51E0MyVo+8Xn55e/Y= =KdZe -----END PGP SIGNATURE-----
On 2005-05-06 21:12:46 +0200, Adrian Rossouw wrote:
Also, one of the benefits of SVN is that it's already reached 1.0 , and there are many gui tools available for it.
Anyone know the benefits of GNU Arch?
i dont know any. svk can give you all of them. my point against arch/tla: The UI just sucks. it is overly complex. darix
On Fri, 2005-05-06 at 22:30 +0200, Marcus Rueckert wrote:
On 2005-05-06 21:12:46 +0200, Adrian Rossouw wrote:
Also, one of the benefits of SVN is that it's already reached 1.0 , and there are many gui tools available for it.
Anyone know the benefits of GNU Arch?
i dont know any. svk can give you all of them.
my point against arch/tla: The UI just sucks. it is overly complex.
What about baz which is a re-write of tla front end in C, and has a few better merging techniques in the backend. I am still evaluating it for another project I am working on. Also one of the thins that I like the most about it that it is very easy to create a read only public repository which can be run on a standard virtually hosted web site. Gordon.
On 2005-05-07 09:36:42 +1000, Gordon Heydon wrote:
What about baz which is a re-write of tla front end in C, and has a few better merging techniques in the backend.
i didnt test that yet. maybe i should. but it is another arch fork (why does everyone fork it? is it so bad?)
I am still evaluating it for another project I am working on. Also one of the thins that I like the most about it that it is very easy to create a read only public repository which can be run on a standard virtually hosted web site.
svnserve -d -r /srv/svn/repos/drupa anon svn done. setting up the same with apache2 is any harder either. darix
On Sat, 2005-05-07 at 13:28 +0200, Marcus Rueckert wrote:
On 2005-05-07 09:36:42 +1000, Gordon Heydon wrote:
What about baz which is a re-write of tla front end in C, and has a few better merging techniques in the backend.
i didnt test that yet. maybe i should. but it is another arch fork (why does everyone fork it? is it so bad?)
I know that tla's command line interface is pretty bad. But then again I never really got into it. When I was at LCA everyone was raving about baz and baz-ng which is backed by Canonical (the backers of ubuntu linux.) for there big launchpad project (which already has drupal in it).
I am still evaluating it for another project I am working on. Also one of the thins that I like the most about it that it is very easy to create a read only public repository which can be run on a standard virtually hosted web site.
svnserve -d -r /srv/svn/repos/drupa
anon svn done.
setting up the same with apache2 is any harder either.
Basically a read only repository is all client side, you can just dump the repository onto the web server. No server side modifications is required. This is good esp. since we are web guys. Gordon.
In my own interest (and speaking for other less CLI-friendly designers than myself), it would be *really helpful* if Drupal used a RCS that had adequate GUI clients for all platforms. SVN has this now and has many people working on it, so that makes it more attractive to me. I also agree with Ber's suggestion, however, that we evaluate our options should we choose to move from CVS. I'm only suggesting that, as the Drupal developer base expands to include non-native CLI speakers, we consider their needs in the move. Chris On 5/6/05, Dries Buytaert <dries@buytaert.net> wrote:
On 06 May 2005, at 19:54, Ber Kessels wrote:
I have been looking around, and read about DARCS (http://abridgegame.org/darcs/) A system that is build purely with decentralized, vuluntary, non-hierarchical communities in mind. IMO it gets much closer to our ideal workflow then SVN will ever get us.
I've been using Darcs for 2-3 months now. Based upon my experience, I would advise against using Darcs:
1. You need to master more commands. It's slightly more complex than CVS.
2. If you delete files from your tree, there is no equivalent to 'cvs -q up -AdP' to get them back. Highly annoying.
3. It is not scalable due to the fact it is written in Haskell.
I'm more interested in 'git', but it might be premature.
-- Dries Buytaert :: http://www.buytaert.net/
Some of the developers at the company that I work at swear by Perforce, which is available for free to open source projects. -----Original Message----- From: drupal-devel-bounces@drupal.org [mailto:drupal-devel-bounces@drupal.org] On Behalf Of Ber Kessels Sent: Friday, May 06, 2005 11:54 AM To: drupal-devel@drupal.org Subject: Re: [drupal-devel] PHPTemplate hits core ... finally Hello, I have been debating this with darix a few times already, but: 1) moving from CVS to SVN must be done when the majority is ready for that. We should thus 1.1) investigate if there are people not at all ready for a move 1.2) investigat who will help with the move. it should never be only on the shoulders of those few who already have a lot on their shoulders (i.e. Dries, kjartan and Steven). 2) If ever we move, we should do it good. Thus look for ALL alternatives, not just look at SVN, because its the closest at hand. IMO SVN is nothing more then a revised CVS. The real problems are not solved, only made a little easier to deal with. SVN continues on a road that, IMO, is not the perfect road for Open source collaboration. The fact that Drupal developement is very much decentralised, non hierarchical and above all voluntary, should be reflected by the RCS we choose to use. SVN gets closer then CVS, but IMO (by far) not close enough. Again, i see it as a slightly improved CVS. but nothing more. I have been looking around, and read about DARCS (http://abridgegame.org/darcs/) A system that is build purely with decentralized, vuluntary, non-hierarchical communities in mind. IMO it gets much closer to our ideal workflow then SVN will ever get us. And yes, I know its easy to sort-of emulate darcs at the client side, while using SVN on the server, but that does not solve the whole idea of SVN simply not being suited enough for Drupals structure and comm. (/. http://it.slashdot.org/it/04/11/25/0136249.shtml?tid=156&tid=218) O, and afaik darcs is about the easiest to learn from the oss RCSs. (http://zooko.com/revision_control_quick_ref.html) But that does not mean we should go for darcs, just now. I simply try to point out we should look at all options, not just choose one, 'cause its been chosen a lot, and thus is the first at hand. We should research, and then choose the best for our system. Ber
Ber Kessels wrote:
2) If ever we move, we should do it good. Thus look for ALL alternatives, not just look at SVN, because its the closest at hand.
IMO SVN is nothing more then a revised CVS. ...
Another alternative to consider is the commercial Perforce software (www.perforce.com). Perforce is industrial-strength -- companies with several hundred or even thousands of developers (including my employer, Adobe) use it day in and day out. I have been using it daily since 1998 both at work and at home (I have my own P4 server for web site development, image management, music storage, among other things) and I highly recommend it. Some things I like about Perforce: * GUI clients for Windows, Solaris, FreeBSD, Mac OS X and Linux * Command-line clients for just about every platform known to man * Detailed permissions model * Sophisticated branching model * Atomic commits * No CVS folders splattered across your workspace * Very efficient use of network bandwidth -- works very well across WANs This software normally costs several hundred dollars per user, but Perforce will offer free licenses to open-source software projects. If interested, I'd be happy to make introductions. There is a CVS-to-P4 conversion tool (see http://perforce.com/perforce/loadsupp.html#conv), but I have never had reason to use it. -Eric -- Eric Scouten Photography | www.ericscouten.com (Drupal powered!) Fine art prints from the world of nature
Doh! I should read the rest of the list before posting. Didn't see the part about the Linux/BitKeeper fiasco. I don't *think* the P4 people would do such a thing, but I can't guarantee it. -Eric Eric Scouten wrote:
Another alternative to consider is the commercial Perforce software (www.perforce.com).
-- Eric Scouten Photography | www.ericscouten.com (Drupal powered!) Fine art prints from the world of nature
This software normally costs several hundred dollars per user, but Perforce will offer free licenses to open-source software projects. If interested, I'd be happy to make introductions.
And will make they some form of legally binding agreement that they will not stop doing so? Think bitkeeper.
Karoly Negyesi wrote:
This software normally costs several hundred dollars per user, but Perforce will offer free licenses to open-source software projects. If interested, I'd be happy to make introductions.
And will make they some form of legally binding agreement that they will not stop doing so? Think bitkeeper.
I'd be happy to ask Perforce for such if there's serious interest on our part. -- Eric Scouten Photography | www.ericscouten.com (Drupal powered!) Fine art prints from the world of nature
On 5/7/05, Eric Scouten <drupal.org@ericscouten.com> wrote:
Karoly Negyesi wrote:
This software normally costs several hundred dollars per user, but Perforce will offer free licenses to open-source software projects. If interested, I'd be happy to make introductions.
And will make they some form of legally binding agreement that they will not stop doing so? Think bitkeeper.
I'd be happy to ask Perforce for such if there's serious interest on our part.
Even if they are interested, I think the Linux/Bitkeeper case teaches all of us a lesson not to depend on the apparent goodwill of companies providing commerical software, because companies and people change, and hence this cannot be guaranteed in the future. The challenge is selecting and converting to one of the other open source options.
FWIW, +1 to *consider* moving Drupal to SVN. It's the one version tracking tool I've been able to figure out so far and be it as it may that I might be completely inept, I think I'm not alone in desiring something a little more "friendly" for code management. Speaking of, has anyone heard of or considered SVK (http://svk.elixus.org/)? svk is a decentralized version control system written in Perl. It uses the Subversion filesystem but provides additional, powerful features. Chris On 5/4/05, Adrian Rossouw <adrian@bryght.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05 May 2005, at 1:35 AM, Gordon Heydon wrote:
<cvs rant>
Darix has showed me some nifty SVN things, and convinced me that we should move Drupal to svn.
- -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin)
iD8DBQFCeV79gegMqdGlkasRAphZAKDWjeuxPnebP0vS+8Y/8q6HTUEjoQCgz80Q 4KIKCky6W1CBxqAwxWZcxDs= =GyD2 -----END PGP SIGNATURE-----
Gordon Heydon wrote:
<cvs rant> Moving the bluemarine PHPTemplate theme into core is one of the main reasons that I am starting to dislike cvs. Because of the move all the history of this is gone, and even the more importantly the credit to me. Also the accountability that this is 100% GPL code is also lost as there is no history before the initial commit.
Umm, well, that's a function of how the move was done, not just CVS -- although I admit CVS doesn't make it as easy as one would like. But bluemarine could have been moved with all history intact. -- Chris Johnson
On 5/4/05, Chris Johnson <chris@tinpixel.com> wrote:
Gordon Heydon wrote:
<cvs rant> Moving the bluemarine PHPTemplate theme into core is one of the main reasons that I am starting to dislike cvs. Because of the move all the history of this is gone, and even the more importantly the credit to me. Also the accountability that this is 100% GPL code is also lost as there is no history before the initial commit.
Umm, well, that's a function of how the move was done, not just CVS -- although I admit CVS doesn't make it as easy as one would like. But bluemarine could have been moved with all history intact.
Really? How? Could you point me / us to some docs or write a quick how-to? This has come up a couple of times, even just within the contrib repository when stuff was being rearranged. I've read the CVS docs (quite a while ago), but I don't remember seeing anything about this type of ability.
Hello, If you read the cvs manual you will see that you actually have to manually move files in the archive itself. The is done outside of the cvs interface. So it is a real pain. Gordon. -----Original Message----- From: drupal-devel-bounces@drupal.org [mailto:drupal-devel-bounces@drupal.org] On Behalf Of Tom Dobes Sent: Thursday, 5 May 2005 1:29 PM To: drupal-devel@drupal.org; chris@tinpixel.com Subject: [drupal-devel] Retaining CVS history over moves (was: PHPTemplatehits core) On 5/4/05, Chris Johnson <chris@tinpixel.com> wrote:
Gordon Heydon wrote:
<cvs rant> Moving the bluemarine PHPTemplate theme into core is one of the main reasons that I am starting to dislike cvs. Because of the move all the history of this is gone, and even the more importantly the credit to me. Also the accountability that this is 100% GPL code is also lost as there is no history before the initial commit.
Umm, well, that's a function of how the move was done, not just CVS -- although I admit CVS doesn't make it as easy as one would like. But bluemarine could have been moved with all history intact.
Really? How? Could you point me / us to some docs or write a quick how-to? This has come up a couple of times, even just within the contrib repository when stuff was being rearranged. I've read the CVS docs (quite a while ago), but I don't remember seeing anything about this type of ability. !DSPAM:427993e798271673159163!
On 5/4/05, Gordon Heydon <gordon@heydon.com.au> wrote:
If you read the cvs manual you will see that you actually have to manually move files in the archive itself. The is done outside of the cvs interface. So it is a real pain.
That's what I thought too... but Chris' message made it seem like it could be done from a client (without manually manipulating the repository). Oh, well... I guess that was just wishful thinking. Thanks for the clarification and sorry for the noise. Tom
If you read the cvs manual you will see that you actually have to manually move files in the archive itself. The is done outside of the cvs interface. So it is a real pain.
That's what I thought too... but Chris' message made it seem like it could be done from a client (without manually manipulating the repository). Oh, well... I guess that was just wishful thinking. Thanks for the clarification and sorry for the noise.
It does not matter, since only the core committers could commit there, and they have direct acccess to the CVS machine too. Goba
Tom Dobes wrote:
On 5/4/05, Gordon Heydon <gordon@heydon.com.au> wrote:
If you read the cvs manual you will see that you actually have to manually move files in the archive itself. The is done outside of the cvs interface. So it is a real pain.
That's what I thought too... but Chris' message made it seem like it could be done from a client (without manually manipulating the repository). Oh, well... I guess that was just wishful thinking. Thanks for the clarification and sorry for the noise.
I guess "real pain" is relative. I assume that the CVS maintainers of Drupal have shell access to the CVS host. As a long-time user of Unix, I don't find moving files outside the CVS interface to be a "real pain." In fact, in some ways it's easier, because the Unix filesystem commands to me are "good old friends" I've been using for years, and the CVS commands are cryptic with lots of odd option flags (I do CVS from the command line; no GUI for me). Surely one would not want to do daily CVS manipulations through the filesystem. But for a once in a year restructuring of core like was just done with xtemplate/phptemplate, it seems like a reasonable thing to do. But that's just me. I'm completely comfortable with the Unix shell command line, and I've been using CVS for a few years, and RCS before that for many years. It is one of CVS's shortcomings, but no version control application is perfect. FWIW, -- Chris Johnson
Tom Dobes wrote:
On 5/4/05, Chris Johnson <chris@tinpixel.com> wrote:
Umm, well, that's a function of how the move was done, not just CVS -- although I admit CVS doesn't make it as easy as one would like. But bluemarine could have been moved with all history intact.
Really? How? Could you point me / us to some docs or write a quick how-to? This has come up a couple of times, even just within the contrib repository when stuff was being rearranged. I've read the CVS docs (quite a while ago), but I don't remember seeing anything about this type of ability.
It's in the "info" documentation for CVS as installed on FreeBSD systems, at least. "info cvs" from the command line, then search for "moving directories". Here is a cut-and-paste of some of the pages. The "Normal way" loses the history. The "Copying the history file" preservees the history. One needs to understand Unix filesystems and how CVS stores its revision history quite well to do this confidently, but it can be done. I've done it half a dozen times or so with my employer's CVS repository. File: cvs.info, Node: Outside, Next: Inside, Up: Moving files The Normal way to Rename ------------------------ The normal way to move a file is to copy OLD to NEW, and then issue the normal CVS commands to remove OLD from the repository, and add NEW to it. $ mv OLD NEW $ cvs remove OLD $ cvs add NEW $ cvs commit -m "Renamed OLD to NEW" OLD NEW This is the simplest way to move a file, it is not error-prone, and it preserves the history of what was done. Note that to access the history of the file you must specify the old or the new name, depending on what portion of the history you are accessing. For example, `cvs log OLD' will give the log up until the time of the rename. When NEW is committed its revision numbers will start again, usually at 1.1, so if that bothers you, use the `-r rev' option to commit. For more information see *Note Assigning revisions::. File: cvs.info, Node: Inside, Next: Rename by copying, Prev: Outside, Up: M\ oving files Moving the history file ----------------------- This method is more dangerous, since it involves moving files inside the repository. Read this entire section before trying it out! $ cd $CVSROOT/DIR $ mv OLD,v NEW,v Advantages: * The log of changes is maintained intact. * The revision numbers are not affected. Disadvantages: * Old releases cannot easily be fetched from the repository. (The file will show up as NEW even in revisions from the time before it was renamed). * There is no log information of when the file was renamed. * Nasty things might happen if someone accesses the history file while you are moving it. Make sure no one else runs any of the CVS commands while you move it. File: cvs.info, Node: Rename by copying, Prev: Inside, Up: Moving files Copying the history file <<<<<<<< This is probably what would be best. ------------------------ This way also involves direct modifications to the repository. It is safe, but not without drawbacks. # Copy the RCS file inside the repository $ cd $CVSROOT/DIR $ cp OLD,v NEW,v # Remove the old file $ cd ~/DIR $ rm OLD $ cvs remove OLD $ cvs commit OLD # Remove all tags from NEW $ cvs update NEW $ cvs log NEW # Remember the non-branch tag names $ cvs tag -d TAG1 NEW $ cvs tag -d TAG2 NEW ... By removing the tags you will be able to check out old revisions. Advantages: * Checking out old revisions works correctly, as long as you use `-rTAG' and not `-DDATE' to retrieve the revisions. * The log of changes is maintained intact. * The revision numbers are not affected. Disadvantages: * You cannot easily see the history of the file across the rename. File: cvs.info, Node: Moving directories, Prev: Moving files, Up: Adding and\ removing Moving and renaming directories =============================== The normal way to rename or move a directory is to rename or move each file within it as described in *Note Outside::. Then check out with the `-P' option, as described in *Note Removing directories::. If you really want to hack the repository to rename or delete a directory in the repository, you can do it like this: 1. Inform everyone who has a checked out copy of the directory that the directory will be renamed. They should commit all their changes, and remove their working copies, before you take the steps below. 2. Rename the directory inside the repository. $ cd $CVSROOT/PARENT-DIR $ mv OLD-DIR NEW-DIR 3. Fix the CVS administrative files, if necessary (for instance if you renamed an entire module). 4. Tell everyone that they can check out again and continue working. If someone had a working copy the CVS commands will cease to work for him, until he removes the directory that disappeared inside the repository. It is almost always better to move the files in the directory instead of moving the directory. If you move the directory you are unlikely to be able to retrieve old releases correctly, since they probably depend on the name of the directories.
3. I moved the XTemplate engine and the Pushbutton theme to the contributions repository. (For almost 2 years XTemplate has been part of Drupal core.)
BTW Xtemplate has a new version, which seems to be maintained. Follow the link in the xtemplate.inc code :) http://sourceforge.net/projects/xtpl/ Goba
participants (15)
-
Adrian Rossouw -
Ber Kessels -
Boris Mann -
Chris Johnson -
Chris Messina -
Dries Buytaert -
Eric Scouten -
Gabor Hojtsy -
Gordon Heydon -
K B -
Karoly Negyesi -
Marcus Rueckert -
Matthew Hildebrand -
Steven Wittens -
Tom Dobes