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

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

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

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/

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 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

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/

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

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.

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.

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

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!

...

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, 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.