General ⇒ DVCS Info (Mercurial/CVS) ⇒ Switching to Mercurial (hg) ⇒ Community Forums ⇒ CPG Dragonfly™ CMS
Forum IndexDVCS Info (Mercurial/CVS)

Switching to Mercurial (hg) Reply to topic


Hey all,

Nano and i decided to switch to Mercurial as our CVS service is getting way to old and is giving complications with integration of other services as it can't be upgraded.
Another problem is that our server is getting very old as well (RedHat 9 since january 2003).

Therefore we've converted CVS to Mercurial repositories at
bitbucket.org/dragonfl...gonfly-cms
bitbucket.org/dragonflycms/l10n
bitbucket.org/dragonflycms/modules

Statistics are gathered through www.ohloh.net/p/dragonfly-cms

The Mercurial GUI we currently use is TortoiseHG

Keep in mind this is a test location and not the final destination as of yet.
Phoenix and anyone else who wants access can contact one of us with his/her gmail address.

I'm still figuring out if we need to update the server OS or upgrade to a new server, but that can be decided later on.

It was my decision to choose Mercurial over GIT as GIT has some issues on Windows OS and there is no x-platform GUI (like TortoiseHG).
Mercurial is similar to GIT (see commands) so the learning curve is not steep.
If someone wants to know the real difference between the two then read this
But ofcourse we're open for suggestions.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Fedora 25 / Apache 2.4.27 / MariaDB 10.1.26 / PHP 7.1.10 / Mercurial

Last edited by DJ Maze on Sun Nov 01, 2015 3:44 pm; edited 2 times in total


Dunno if it makes much diff to rest of us, whichever of git or Mercurial suits you guys best.

I see Mercurial is supported by Geany just like GIT (at least outside of Windows) so that's good.

One feature I like on git, which I think is actually a github one, is a "grab as a zip" button, which makes it VERY easy for non-developers to grab a copy - as an easily understood .zip file - at any time. Presumably we'll still need a regular latest build, equivalent to the old 6hr CVS build?

One question about DFv9 access though: Under CVS it was possible, albeit at the loss of the diff display, to get at the individual module versions as they relate to DF9; will the same be possible under Mercurial? If so, how/where?

But 1 problem I'm seeing is that the CVS source info is dropped retroactively. I understand completely why it is being dropped going forward, but without it retained (not updated) in DFv9 versions, there is no way to correlate what is in Mercurial (nee CVS) and what's already on our servers (as there is not a Mercurial hash # in already released versions).

Would it be better to keep old v #'s in Mercurial (as text) for at least v9, than keep CVS around just for v9 (which seems to me to be the other option)?

Pro_News CM™ - Content Management for Dragonfly CMS™

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux / 1.3.39 - 2.4.9 / 5.5.42 - 5.6.16 / 5.4.37 - 5.5.11 / 9.4


It's all there (with some trouble though).
I used Mercurial Convert extension to convert the whole cvs and each change since 2004 is there.

The trouble is that files with multiple branch/tags are not placed in each branch, they were only inserted in the first branch.
Nano discovered this while working on the Df-9_2_1 branch, he had to add all missing files manually.

So, all the changes are there just a bit scattered all over the place.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Fedora 25 / Apache 2.4.27 / MariaDB 10.1.26 / PHP 7.1.10 / Mercurial


When all is done a "v9" branch will be put in place

.:: I met php the 03 December 2003 :: Unforgettable day! ::.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
CloudLinux / Apache 2.4 LSAPI / MySQLi 5.6 / PHP 5.6 / DCVS


NanoCaiordo wrote
When all is done a "v9" branch will be put in place

Excellent!

To my other point, I was referring to these lines (from admin/modules/blocks.php in this case):
  $Source: /cvs/html/admin/modules/blocks.php,v $
  $Revision: 9.41 $
  $Author: nanocaiordo $
  $Date: 2007/10/03 13:51:39 $

Suggesting these lines be retained - as static text only - in the code released originally under CVS, to facilitate locating/comparing code already installed in user's public.html with the source repository. At least the critical (unique) Revision line, and perhaps the date one too.

Pro_News CM™ - Content Management for Dragonfly CMS™

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux / 1.3.39 - 2.4.9 / 5.5.42 - 5.6.16 / 5.4.37 - 5.5.11 / 9.4


All the CVS keywords are removed as it is not right to use it.

There is a far much better deal with Mercurial which i explain!

When you clone the repository you can make changes and commit these changes as well.
Hack, you can make your own tags and branches when needed.

Then when you want the latest versions of Dragonfly you "pull" all code from our repository and see all revisions.
Right-click on the revision you want to upgrade to and choose "merge with local".

Mercurial will then try to merge all Df changesets into your locally modified version.

This way you have full control over your "modified" Df sources and the abillity to upgrade without loosing your changes.

When you try and play with this, you will notice this is far much better then CVS.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Fedora 25 / Apache 2.4.27 / MariaDB 10.1.26 / PHP 7.1.10 / Mercurial


No, no, no, I'm not getting my point across ...

I understand reason to MOVE TO mercurial. I use github for reDesign3+ already. Hash is better, etc., etc.

The issue I'm raising concerns the legacy code which is already out running somewhere - ie the current v9 code - on our hosts. If I have a problem with my legacy code, today I can look up the version number of the module, then go into CVS and find the exact same version, and trace the updates.

If we go to Mercurial how do I do that? My legacy code has version numbers not hashes, and the mercurial sources have only hashes, no version numbers.

Without the version number, carried as a comment, in mecurial, then we'll need to keep the CVS around until the last user has moved to v10 - which could be a very, very long time!

We need to move away from CVS asap (diffs have already gone from v9 in CVS), but not in a way that rewrites history.

Pro_News CM™ - Content Management for Dragonfly CMS™

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux / 1.3.39 - 2.4.9 / 5.5.42 - 5.6.16 / 5.4.37 - 5.5.11 / 9.4


Understand, but tracking files based on the revision number inside the file is just plain wrong (even in git).
When someone screws around he should keep track of changes himself (that's where DVCS jumps in).

The old CVS will stay online for the old v9 users, but yeah they can't rely on numbers in files anymore.
In DVCS Individual files don't have a number anyway, you use the same number for a whole tree/manifest.
So when uploading to a server you can just create an empty file ".hg-[revisionnumber]" to know which revision is used on that server.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Fedora 25 / Apache 2.4.27 / MariaDB 10.1.26 / PHP 7.1.10 / Mercurial


Mercurial is great!

Don't know exactly why you preferred it over git, but probably because git is known to have quite extensive learning curve (in case you get in trouble).

A good IDE can also point out how in time a single line has changed, so not having the old CVS should be OK, though could be left as read-only to match the old cvs revisions if there is a specific need.

So next steps could be:
Fully OO design & readable code for new code (I'm a Java EE developer atm, so maybe I want too much from PHP), but then again, there is so much legacy...

What I mean is, there is some stuff that is great, and some which should be thrown away to software-heaven where cobol, PHP-Nuke and other friends live.

Actually, maze developed Moo CMS, which seemed like a replacement for DF with much better architecture.

Does the CMS (not specifically Dragonfly CMS) still interest you or you try to keep it artificially alive? Or it's just a nice hobby-project? Is there something DF has other CMS-s don't have? Or some ideas it could have that other's don't have or better implementations? It might sound like a rant, but it's just out of pure curiosity.

Yours faithfully,
Madis

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
-


@layingback:
v9 is in DCVS from a while now.



@Eestlane:
Mercurial has good GUIs for either Windows, Linux and Mac.
Old CVS will be kept alive for readonly, at least while we are using this same server.
Artificially alive? No.
Something DF has and others don't? No idea about this, but under the bonnet we now have a better SQL layer (support prepared queries, write to master and read from slave, etc etc), a better installer (and still many improvements have to come), fully support for IPv6, better firewall with DNSBLs and many new features and much much more.
I personally can't compare DragonflyCMS with others, I can only list software's features.

.:: I met php the 03 December 2003 :: Unforgettable day! ::.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
CloudLinux / Apache 2.4 LSAPI / MySQLi 5.6 / PHP 5.6 / DCVS

All times are UTC


Jump to: