From: Andrzej J. T. <an...@ch...> - 2010-03-26 16:02:23
|
Guys (hey...don't we need some female eXist developers? ;-) ): I believe that some of the problems that we've seen with functions spread across multiple commits, partial commits of new features and the like might be partially due to, or at least exacerbated, by our use of a "classic" source code control system like Subversion. Branches and merges are a real pain with a tool like Subversion for anything beyond simple changes. Now don't get me wrong....I've used Subversion for a long time and like it, and do not relish learning a new approach or giving up my current SVN tool of choice (the Oxygen SVNClient tool).... But as our ranks get larger and the subprojects people are interested in and work on become bigger and more elaborate, maybe we should consider moving to a DVCS - Distributed Version Control system, which would provide much more flexible and easier branch/merge capability? Might help alleviate some of the issues in the longer term. Something like GIT or Mercurial.... For those not familiar with DVCS's, Joel Spolsky posted a great article on DVCSs here: http://www.joelonsoftware.com/items/2010/03/17.html Thoughts? -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Adam R. <ad...@ex...> - 2010-03-26 16:11:04
|
> But as our ranks get larger and the subprojects people are interested in and work on become bigger and more elaborate, > maybe we should consider moving to a DVCS - Distributed Version Control system, which would provide much more flexible > and easier branch/merge capability? Might help alleviate some of the issues in the longer term. > > Something like GIT or Mercurial.... > > For those not familiar with DVCS's, Joel Spolsky posted a great article on DVCSs here: > > http://www.joelonsoftware.com/items/2010/03/17.html > > Thoughts? Mercurial sounds very interesting and SourceForge even have some support for it - http://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial However, the biggest limitation in my mind is that write access to repository can only be achieved over SSH. Before we moved to Subversion, CVS used to be a major pain in the ass for me, because I work from far too many locations (offices, airports, trains, cafes etc) where the only access out is HTTP, Subversion works perfectly over HTTP. If SourceForge were to enable Mercurial writes over HTTP then I might be sold on the idea ;-) > -- > Andrzej Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Andrzej J. T. <an...@ch...> - 2010-03-26 19:24:14
|
Adam: > Mercurial sounds very interesting and SourceForge even have some > support for it - > > http://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial Cool....I didn't know that sf had support for Mercurial. That's good to know. > However, the biggest limitation in my mind is that write access to > repository can only be achieved over SSH. > > Before we moved to Subversion, CVS used to be a major pain in the ass > for me, because I work from far too many locations (offices, airports, > trains, cafes etc) where the only access out is HTTP, Subversion works > perfectly over HTTP. If SourceForge were to enable Mercurial writes > over HTTP then I might be sold on the idea ;-) Yeah...that might be a problem with firewalls and the like blocking the standard SSH port 22. I wonder if git suffers from the same issue. Or maybe there are other hosting providers like sourceforge that support Mercurial over plain HTTP? Worse case, we could set up a relay/proxy that would expose HTTP and relay over SSH to sourceforge. However, first we probably need to discuss the pros/cons of DVCS for the eXist project, timelines and then which DVCS to use, who would host the repository and so forth....so it's a long path still before we would even get there. I just figured it would be good to at least start a discussion on the topic and see what everyone thinks. ;-) -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Thomas W. <tho...@gm...> - 2010-03-26 16:20:00
|
Here is a list of free hosting of Mercurial repositories http://mercurial.selenic.com/wiki/MercurialHosting Thomas ----- Original Message ----- From: "Adam Retter" <ad...@ex...> To: "Andrzej Jan Taramina" <an...@ch...> Cc: "eXist development" <exi...@li...> Sent: Friday, March 26, 2010 4:10 PM Subject: Re: [Exist-development] DVCS - Distributed Version Control? >> But as our ranks get larger and the subprojects people are interested in >> and work on become bigger and more elaborate, >> maybe we should consider moving to a DVCS - Distributed Version Control >> system, which would provide much more flexible >> and easier branch/merge capability? Might help alleviate some of the >> issues in the longer term. >> >> Something like GIT or Mercurial.... >> >> For those not familiar with DVCS's, Joel Spolsky posted a great article >> on DVCSs here: >> >> http://www.joelonsoftware.com/items/2010/03/17.html >> >> Thoughts? > > Mercurial sounds very interesting and SourceForge even have some > support for it - > > http://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial > > However, the biggest limitation in my mind is that write access to > repository can only be achieved over SSH. > > Before we moved to Subversion, CVS used to be a major pain in the ass > for me, because I work from far too many locations (offices, airports, > trains, cafes etc) where the only access out is HTTP, Subversion works > perfectly over HTTP. If SourceForge were to enable Mercurial writes > over HTTP then I might be sold on the idea ;-) > >> -- >> Andrzej Taramina >> Chaeron Corporation: Enterprise System Solutions >> http://www.chaeron.com >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Exist-development mailing list >> Exi...@li... >> https://lists.sourceforge.net/lists/listinfo/exist-development >> > > > > -- > Adam Retter > > eXist Developer > { United Kingdom } > ad...@ex... > irc://irc.freenode.net/existdb > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > |
From: Andrzej J. T. <an...@ch...> - 2010-03-29 23:27:22
|
Adam: > Before we moved to Subversion, CVS used to be a major pain in the ass > for me, because I work from far too many locations (offices, airports, > trains, cafes etc) where the only access out is HTTP, Subversion works > perfectly over HTTP. If SourceForge were to enable Mercurial writes > over HTTP then I might be sold on the idea ;-) Bitbucket (mercurial hosting) supports both HTTP and SSH access for both pull and push, and has free services for open source projects. Github (git hosting) has free services for open source, but I'm not sure if you have to use SSH or not yet. So there are a number of alternatives to Sourceforge for DVCS. Just FYI. -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Adam R. <ad...@ex...> - 2010-03-30 10:02:58
|
Moving away from SourceForge would seem a little extreme to me, and certainly would raise larger questions than just what SCM we use. Perhaps it would be worth contacting sourceforge and finding out what their plans for Mercurial are? They are only trialling it at the moment, so I guess they will have a roadmap for making it a primary service and probably offering a http service. On 30 March 2010 00:27, Andrzej Jan Taramina <an...@ch...> wrote: > Adam: > >> Before we moved to Subversion, CVS used to be a major pain in the ass >> for me, because I work from far too many locations (offices, airports, >> trains, cafes etc) where the only access out is HTTP, Subversion works >> perfectly over HTTP. If SourceForge were to enable Mercurial writes >> over HTTP then I might be sold on the idea ;-) > > Bitbucket (mercurial hosting) supports both HTTP and SSH access for both pull and push, and has free services for open > source projects. > > Github (git hosting) has free services for open source, but I'm not sure if you have to use SSH or not yet. > > So there are a number of alternatives to Sourceforge for DVCS. > > Just FYI. > > -- > Andrzej Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Andrzej J. T. <an...@ch...> - 2010-03-30 18:54:28
|
Adam: > Moving away from SourceForge would seem a little extreme to me, and > certainly would raise larger questions than just what SCM we use. I'm not sure that who provides the hosting is such a big deal. So long as they have been around for a bit and have a good track record. Both github and bitbucket would seem to be pretty "safe" alternatives. > Perhaps it would be worth contacting sourceforge and finding out what > their plans for Mercurial are? They are only trialling it at the > moment, so I guess they will have a roadmap for making it a primary > service and probably offering a http service. Good suggestion....I'll see if I can get through to someone there in the next week or so. -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Dannes W. <da...@ex...> - 2010-03-30 10:16:07
|
Hi, On Tue, Mar 30, 2010 at 12:02 PM, Adam Retter <ad...@ex...> wrote: > Moving away from SourceForge would seem a little extreme to me, and > certainly would raise larger questions than just what SCM we use. > > Perhaps it would be worth contacting sourceforge and finding out what > their plans for Mercurial are? They are only trialling it at the > moment, so I guess they will have a roadmap for making it a primary > service and probably offering a http service. For me, tooling support is the most important factor here. At this moment, as far as I see, SVN is the most commonly used way for code management. Existing tooling is just excellent (tortoisesvn, svnkit, etc) and .... existent. I fear that a switch would 'ruin' this situation. The current SVN does not hurt me in any way, so I do not see the benefit of another system, at least not at this moment. D. -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
From: Dmitriy S. <sha...@gm...> - 2010-03-30 16:05:06
Attachments:
smime.p7s
|
On Tue, 2010-03-30 at 12:15 +0200, Dannes Wessels wrote: > Hi, > > On Tue, Mar 30, 2010 at 12:02 PM, Adam Retter <ad...@ex...> wrote: > > Moving away from SourceForge would seem a little extreme to me, and > > certainly would raise larger questions than just what SCM we use. > > > > Perhaps it would be worth contacting sourceforge and finding out what > > their plans for Mercurial are? They are only trialling it at the > > moment, so I guess they will have a roadmap for making it a primary > > service and probably offering a http service. > > For me, tooling support is the most important factor here. At this > moment, as far as I see, SVN is the most commonly used way for code > management. Existing tooling is just excellent (tortoisesvn, svnkit, > etc) and .... existent. Mercurial don't have problems in tools with GUI ( http://en.wikipedia.org/wiki/Mercurial ). Current problem is http assess only, proxy can solve it. I did start one project on Mercurial & I'll share my experience as soon as get them ;) > I fear that a switch would 'ruin' this situation. The current SVN does > not hurt me in any way, so I do not see the benefit of another system, > at least not at this moment. > > D. > -- Cheers, Dmitriy Shabanov |
From: Andrzej J. T. <an...@ch...> - 2010-03-30 18:48:55
|
Dannes: > For me, tooling support is the most important factor here. At this > moment, as far as I see, SVN is the most commonly used way for code > management. Existing tooling is just excellent (tortoisesvn, svnkit, > etc) and .... existent. Yup...but the tooling is coming up fast with DVCS implementations. The fact that Linux uses git says a lot. > I fear that a switch would 'ruin' this situation. The current SVN does > not hurt me in any way, so I do not see the benefit of another system, > at least not at this moment. It's not that SVN is "broken" in any way. I'm very comfortable and used to it as well. I prompted this discussion only because DVCS systems like git or mercurial might make it a bit easier for all of us to branch and merge experimental code (since we've had a few pain points that this recently). So I thought it would be worth discussing whether those possible benefits might outweigh the negatives of doing a switch. One thing that is very interesting is that you can use git, backed by an SVN repository as an interim step. Check this out if you are interested in that idea: http://progit.org/book/ch8-1.html Interesting concept.... -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |