A suggestion for submitting code change and sharing experimental work

[lingo]

I am experimenting distributed revision control packages lately. my criterial for the packages are easy to setup and use, and support both windows and linux/bsd.

so Arch is out because it hardly supported windows, cygwin doesn't count. svk is just very tough to setup, I had high hope for monotone, but after setting it up and playing it for a few days, I felt that it not easy enough to learn and use for non-techie. Somehow, I stumbled across Darcs, So I tried it today, setup in half hour, produtive in 10 minutes. It just so easy to use and tremedously useful.

Let consider a scenarios. Suppose a newbie come along and want to contribute, so he/she installed Darcs and pull source from repository to the current directory

Code: Select all

darcs get http://www.uox3.org/uox3

the newbie fiddle around the files, fixes some bugs, and he/she committed the change to local repository

Code: Select all

darcs record -am "fix bugs."

newbie want to email the changeset to maintainer, that you giwo, so he/she do

Code: Select all

darcs send -a

that all. much easier then diffs files; and got a full source code control system to his/her source code to boot.

Darcs has a lot of advantages. Easy Branching, Linus Mode, Parallel Development, Easy Local Revision Control, and Cherry Picking. Darcs Getting Started explained it in detail. t also easy to roll back and undo change
. And when Giwo and Xuri are ready to released a new version. They can committed the source codes to sourceforge CVS then release it.

dfn, scripts files can also be made too share under the same scheme. we only needs http/ftp and Darcs installed on the server to do the sharing.

I am going to do some rather disruptive code changes to UOX3, and it more of a proof of concept, so Darcs is a easy way for other developer/user to try my changeset and commenting on it.

After reading through DarcsWiki. I am excited about other possibilities, there is a lot more things we can do, and the best part, it just so easy to setup and use.

[punt]

Seems like that is all ready there, and universally available.

One can easiy do read, and do patches from that for submital.

Just doesn't seem to be a big need for more effort then what is all ready available.

And one less thing for many "devs" to install (many would probalby all ready have a cvs client /svn client).

[lingo]

First, It all about productivity. you can do diffs and submitted but it slower and easier to get wrong.

all 'devs' should have a private source revision control system, it just make trying out code change much easier, you can make private branches, roll back changes, and merge third party change etc....

Now take another example. Grimson is make a lot of valuable addition in the code right now. But currently, everybody has to copy paste from forum posting to try out the addition. Now if Grimson have Darcs, he can either put it on the web, so we can pull the changeset , or we can request a changeset from him, which Grimson does not have to do explicitly, Darcs handle it automatically. And any further enhancement we make, we can just email it back easily.

So experimental code change and testing is done much easier and much earlier, without much hassle.

I quote directly some of the advantages from Darcs' wiki.

* [WWW] Offline mode. You can commit changes even if you're on the road with no access to the server. That's because your own working directory is a repository in its own right. When you get home, you do a "darcs push" to commit to the public server.

*Easy branching. Every repository is a branch. Working on implementing some feature but need to fix a bug? You don't want to check in your work in progress just to check in a bugfix, so you branch off the trunk and work on the fix.

*Linus mode. I want to add a feature or bugfix to an open-source project. I make a local Darcs copy, apply my changes, then send my changes by email ("darcs send"). The project's maintainer(s) can decide whether to accept or reject the changes. This way, you don't necessarily need to screw around with commit privileges. This is how Darcs itself is maintained, by the way. This is also similar to the way Linux is/was maintained, except the process is implemented in software.

*Parallel development. Let's say I follow the development of this open-source project, and I have some "controversial" patches that aren't accepted by the official maintainers. No problem -- I make my changes, release my own distribution. It's a fork, of sorts, but it's still connected to the mainline. Whenever the official project makes changes, I do a "darcs pull" to get them, and resolve any conflicts. This way, my fork is kept up to date with the main project's repository.

*Easy local revision control. CVS/RCS is popular for versioning home directories, /etc, etc. With Darcs you get the simplicity of RCS with the power of, well, Darcs. Maintaining the same config on a myriad of PCs becomes easier, not least because Darcs supports pushing of changes; I can make changes and push them to all my servers with a single command.

*Cherry-picking. If you've ever worked on a team, you will know that somebody often has a change you want, but which can't be committed to the trunk yet. With Darcs you can grab just the one change by pulling it into your repository.

[punt]

Never argued over productivity, but as in all things, there is a sweet spot, which after one gets dimishing returns.

To make one persons code changes easier for one dev to incorperate (for after accepted, they could just udate the cvs with it), all must download and install something (and learn) a new thing.


Not arguing it provides benifits, but the time spent NOW to set that up, versus working the code, doesn't seem to warrant (again, at this time) a large enough return.

But again, this is just my opinion. Clearly if the devs feel it saves time and there is a demand, by all means it should be done.

[lingo]

Not arguing it provides benifits, but the time spent NOW to set that up, versus working the code, doesn't seem to warrant (again, at this time) a large enough return.

That why I rejected monotone, which takes a few days to master. It really easy to setup Darcs even for windows.

The basics (with or without Cygwin):

* Download darcs.exe from [WWW] http://glozer.net/darcs/

To enable access of remote repositories over ssh (with or without Cygwin, if you want to use ssh):

*Download pagent.exe, puttygen.exe, plink.exe, and pscp.exe from [WWW] http://www.chiark.greenend.org.uk/~sgta ... nload.html
*Download sftp.zip from [WWW] http://www.hck.sk/~peter/sftp_for_win32_darcs/
*Put darcs.exe, plink.exe, pscp.exe, sftp.zip, pagent.exe, and puttygen.exe in an empty directory.
*Rename plink.exe to ssh.exe and pscp.exe to scp.exe; uncompress sftp.zip. Ensure that all these .exe files, including the "sftp.exe" that results from uncompressing sftp.zip, have permissions that allow you to execute them. If you are using cygwin, you can use "chmod ugo+x FILENAME" to enable execute permissions for each file.
*Set up passwordless ssh login as described on this page: [WWW] http://www.tartarus.org/~simon/puttydoc ... r8.html#C8

Finally (without Cygwin):

*Add the directory where you stored the executables at the beginning of your path.

If you don't want remote repository write with ssh. 5 minutes, and even with ssh it takes less than half hour to set it up. And to be proficient with Darcs, it only takes a few minutes. It really that easy.

For a newbie without CVS tools. Darcs is faster, easier, and more productive. Again, even a casual uox3 user can contribute because it so easy to setup.

Open source movement is moving to distributed revision control for a few years now. Linus would not use CVS/Subversion for quite a few years, he use proprietary solution before moving to git. Distributed revision control is really quite a productivity boost.

I understand that people don't want to change, why fix something that isn't broke. And I am not in a position to demand the change. Still using Darcs make life so much easier for me, I just want to share it and hopefully makes everybody more productive.

[Sydius]

I just learned CVS, and I like it. It was super easy to install and use (thanks to Xuri’s little tutorial), and I like the way it works.

About private version control, though, couldn’t you just set up your own CVS “module” thingy, and use that? I know the turtle CVS program lets you do that… dunno if you can on the same folder as another CVS project, but it would just be a matter of copy/paste if not, right?

[lingo]

About private version control, though, couldn’t you just set up your own CVS “module” thingy, and use that? I know the turtle CVS program lets you do that… dunno if you can on the same folder as another CVS project, but it would just be a matter of copy/paste if not, right?

No, turtle CVS is just a client, not a server. The uox3 CVS repository is on sourceforge, so your local version must sync against it. You must setup your own local CVS server, such as CVSNT for windows, to have private version control. Still you cannot merge your private version of uox3 and the public version easily. You have to do it manually, check which version has the newer version for each files, diffs it, and merge it.

It messy, and it not what CVS was designed to do. CVS was designed so that everyone will sync against a central repository, and if you want a experimental or private version, branch it. The problem is, you don't want everyone comes along to have write access to CVS, and especially not administrative right.

So I could not just get together with you for examples, and setup a new experimental version of cMapStuff, and if we are satisfied with the result, we sent the changeset to giwo and Xuri for their approval. It just very difficult or very dangerous to use CVS to do a lot of thing.

Darcs make the above case easy, the concept is easy, the setup is easy. The only requirment is that you are at least familiar with command line. Once you use distributed revision control, you would never go back to CVS. Linus couldn't, so when bitkeeper withdraw the free version, he create git to replace bitkeeper.

[lingo]

CVS also don't allow for metadata changes. Moved files will not be listed, and new files will not be created when another developer runs this diff through patch.

Linux kernel use to have a development version 2.5x, and a stable version 2.4x.
But now there is only 2.6x. Why? distributed revision control makes experimental, and other highly disruptive changes easy to manage. Maintainer only merge in new features that they like, yet people can still try various stuffs without diverging from the mainline.

Distributed revision control makes restructuring of files or directory easy. I think that one of thing we want to do in uox3.

[Xuri]

lingo: Sounds to me like a good way of letting people participate and contribute without necessarily handing out CVS write access left and right. And we won't have to create numerous CVS branches, either. Look at the sf.net/projects/uox3 cvs - it's a mess because of all the different branches.

[lingo]

lingo: Sounds to me like a good way of letting people participate and contribute without necessarily handing out CVS write access left and right. And we won't have to create numerous CVS branches, either. Look at the sf.net/projects/uox3 cvs - it's a mess because of all the different branches.

Exactly. you can limited CVS write access to just a few core maintainer, and CVS branches is not exactly easy to use and merge too.

Looking back at my posts, I realized I did not make my cases clearly. I just mumbled about productivity increase without stating the specific. So this is another example.

Linus reverted ACPI patch show that you can reverted submitted patches easily even if it accepted already. You can do that because the patch(changeset) is submitted as a logical group with metadata changes. CVS cannot do that, CVS don't have metadata, so you have to reverted file by file, which is easy to get messed up.

Able to revert a patch is very important. Because some patch will introduce more problems than it solved, but we did not realized the problems after numerous other patches are incorporated, with CVS it is hard to undo the problematic patch at that point.

Take an example, in [VERIFIED] Bug: Sea creatures can't move in water, punt has some good ideas about how we should change the code. We did not implement the suggest change not because it hard or because we are lazy; it just that we are afraid if the change will cause more problems than it solved, or we don't know who should change that code. With Darcs, or other similar packages, we can still pulled this changeset long afterward, this give us more freedom to experiments.

[Sydius]

You do not need a CVS server to make a local “module” with Turtle CVS – it has that capability built in. I read so in the documentation.

[lingo]

You do not need a CVS server to make a local “module” with Turtle CVS – it has that capability built in. I read so in the documentation.

You are right, I just read the tortoiseCVS faq. tortoiseCVS can be used for local repository. Sorry about the misinformation.

Still, there is no auto way to merge your local repository with the main repository.

[punt]

That why I rejected monotone, which takes a few days to master. It really easy to setup Darcs even for windows.

Again, the context. It can be easy, but what is the demand for it? On person submitting?

For a newbie without CVS tools. Darcs is faster, easier, and more productive. Again, even a casual uox3 user can contribute because it so easy to setup.

In this case the argument is more for JS then code. You are making an assumption on what a "newbie develoer" may find easy. But I think it is now asking anyone to suddenly download another tool for JUST uox (while cvs they are mikely to use for other things as wel l). But at this point we are both just speculating what a "dev" may or may not have/find easy.

Open source movement is moving to distributed revision control for a few years now. Linus would not use CVS/Subversion for quite a few years, he use proprietary solution before moving to git. Distributed revision control is really quite a productivity boost.

You are not comparing equivlent things. You do not need to argue the benifits of distributes in large scale environments. I understand that. But UOX is not a large scale. It is not the same context.

There are tons of autmation that many large scale buisness do (any branch). That would never be cost effective for single person shops. Just not enough benifit given the context. That is what I am questioning here. Not the theory or the benifit in large scale, but if UOX really has the problem in a scale large enough to warrant something. How big and frequent is the problem.

One does not need to argue that a backhoe or bulldozer is far more effiencent for digging holes. But if I only need to dig a small hole, less then once a month, is it really worth all the trouble (no matter how easy it is to get one delivered for the day I need it). Especially if I all ready have a shovel.
It goes to the NEED. I personally don't see UOX experiencing that need. And it can be harmful. If suddenly anyone who wants to help, feels they need to show up with a bulldozer versus their shovel, many may jsut say, why bother. Especially if this is the only project that requires the said bulldozer.

I understand that people don't want to change, why fix something that isn't broke. And I am not in a position to demand the change. Still using Darcs make life so much easier for me, I just want to share it and hopefully makes everybody more productive.

Not a change issue, but a context one. You are correct, I am questioning how broken is it? I know I and other devs I work with are reluctant to start work on a project that requires one to download tools that I don't commonly use for other projects. Especialy if it is a small niche project (not something like the linux kernal, apache, etc).


Please note I am just giving you my opinon. It doesn't matter what I think, I am not involved in UOX at all. Just discussing. So it matters not if thought it was good or bad. Just gwio, Maarc, and perhaps Xuri are all that matter.

[xir]

One of the main reasons most people probably go with cvs is because sourceforge hosts the repository server for free. With other products there is the issue of hosting and maintaince. Sourceforge offers a number of fairly reliable services for the management of opensource projects. SVN also seems to be getting more popular. Wolfpack have moved their repository to BerliOS which is something like sourceforge except with support for SVN. At the end of the day, does it really matter what is used? Most people who want to contribute to UOX are only contributting small specific amounts of code or bug fixes.

[lingo]

One of the main reasons most people probably go with cvs is because sourceforge hosts the repository server for free. With other products there is the issue of hosting and maintaince. Sourceforge offers a number of fairly reliable services for the management of opensource projects.

true, and it still will be used, but only by the main maintainers, giwo, maarc, xuri ...etc.

SVN also seems to be getting more popular. Wolfpack have moved their repository to BerliOS which is something like sourceforge except with support for SVN. At the end of the day, does it really matter what is used? Most people who want to contribute to UOX are only contributting small specific amounts of code or bug fixes.

true, subersion is CVS++ and gaining popularity, One of the primary advantage of the SVN is that it support metadata and atomic commits, which help svn support a limited changeset like operation. see http://subversion.tigris.org/faq.html#changesets

It the small code and bug fixes that benefit the most from changeset. You can commit/revert a changeset to test if the bug is fixed or more bugs are created. It really help maintainers in managing the projects, automation equals less work.