|
Sun 26 Feb 2006 03:21:30 PM UTC, comment #8:
(Off-Topic)
I see that Tom Lord is back in the game for Arch. Well, reading http://lists.gnu.org/archive/html/gnu-arch-users/2006-02/msg00016.html just confirms what I already thought and keeps my expectations for this project über-low.
Well, no surprise, I'm more into legalism than anarchism, I don't like over present competition-spirit "defeating Subversion, defeating Bitkeeper".
"helping to advance Savannah" eminds me that 3 years ago, I worked with several persons from arch to make it working properly on savannah.gnu.org. I did not even remembered that sv.gnu.org had arch support before FSF USA decided to kick FSF France people from its management.
Weird, I should run memtest86 on myself :))
But the return of Tom Lord surely means that tla won't simply be replaced by bazaar.
|
Sun 26 Feb 2006 02:40:18 PM UTC, comment #7:
> Well, it doesn't look so odd if you see Arch as some kind of prototype to
> establish a new kind of version control, to overcome some limitations which
> have been in place for the last couple of years.
Seems to me like GNOME: everything changes before getting production ready, it is unreliable as hell.
I would never base any real work/business on such software. Big announces, big claims, not much in the end.
I do not see any real limitations to SVN, its fixes the one CVS had.
The whole "distributed" thing is not really a technical issue but a project management one. Personally, I'm not a big fan of such decentralized model, not for State organization, not for software development.
But that's indeed nothing more but an opinion.
> Sure, no doubt. However, it'll be a cleaner implementation and much more
> modular afterwards. At least that's what I expect from the code change.
Sometimes some deep down code changes with no real visible difference for the end user are necessary.
While useful, it's sometimes hard to spend lot of time while in the end it makes no differences too users.
We are exactly in such case. It
> About the homepage: If I remember correctly, users can only use CVS for
> version control currently, correct?
It is a group type. Admins choose which version control system is to be used.
|
Sun 26 Feb 2006 02:26:34 PM UTC, comment #6:
> But actually bazaar and Arch are compatible or almost the same
> thing.
True.
> Arch is not even 4 years old software and it is already the
> time to restart from scratch something else by learning from
> its mistakes?
Well, it doesn't look so odd if you see Arch as some kind of prototype to establish a new kind of version control, to overcome some limitations which have been in place for the last couple of years.
> Ok, but such approach will not be an easy code change. Plenty
> of changes will have to be made. Because the way arch and svn
> support was implemented was the easy way: duplicating CVS
> fields.
... and that's exactly what I want to avoid this time :)
> Ok, I like this idea of having only one page for all sources,
> whatever they are. But we have to keep in mind what would
> happen for instance if a project using SVN for its software
> source code but CVS for its homepage sources. It would mean
> that info about SVN and infos about CVS should be printed.
> That's doable but we have to think a bit on the way to do that
> cleanly.
Sure, no doubt. However, it'll be a cleaner implementation and much more modular afterwards. At least that's what I expect from the code change.
About the homepage: If I remember correctly, users can only use CVS for version control currently, correct?
|
Sun 26 Feb 2006 02:12:37 PM UTC, comment #5:
Incidentally "As of August 2005 Canonical has decided to focus our ongoing efforts on the Python Bazaar-NG codebase" (http://bazaar-vcs.org/BzrFAQ#head-3d5a7fba6dfa6c00e192b71597db5c42b4251ef5) while GNU Arch is now maintained by Andy Tai (http://lists.gnu.org/archive/html/gnu-arch-users/2006-02/threads.html shows activity).
|
Sun 26 Feb 2006 12:26:12 PM UTC, comment #4:
> As I said in the original submission, I think the usage of Arch is fading out.
> Most people nowadays use its successor, bazaar, because it is much simpler to
But actually bazaar and Arch are compatible or almost the same thing. If I remember well, it is bazaar that is installed at arch.gna.org
> use. Moreover, there are even better alternatives, which have learned from the
> mistakes made by Arch, to provide even simpler and straight-forward version
> control.
Arch is not even 4 years old software and it is already the time to restart from scratch something else by learning from its mistakes? Well, it looks to me that some people that were boldly pretentious in their time (I remember some messages from people quite sure that their system would be the one used worlwide in a few month, killing all others competitors... two years ago). It also looks to me that there's a trend regarding SCMs (probably because there is indeed a valid business model behind) that push plenty of people to start their own homemade SCM - but I guess this trend will last.
> I'm afraid you got me wrong, then. I wasn't suggesting to add new fields to
> the database. In fact, almost every field needed is already in the database.
> The modular approach was just what I had in mind.
Ok, but such approach will not be an easy code change. Plenty of changes will have to be made. Because the way arch and svn support was implemented was the easy way: duplicating CVS fields.
> If I remember correctly, there have been quite a few support requests on
> Savannah to integrate the Arch version control system. It's just likely that
> its successors are wanted, too.
Unless I'm mistaken, they still miss SVN. So I doubt they are so eager to add one more SCM anytime soon.
> Savane. The only thing I'd like to change is to have a nicer support interface
> in the project's pages for it. We don't need to add menus for each and every
> SCM, in fact, I discourage us to do so. There should be just one menu item,
> called "Sources", which would link to the appropriate version
> control system. Also, we wouldn't need to provide a web browsing
Ok, I like this idea of having only one page for all sources, whatever they are. But we have to keep in mind what would happen for instance if a project using SVN for its software source code but CVS for its homepage sources. It would mean that info about SVN and infos about CVS should be printed.
That's doable but we have to think a bit on the way to do that cleanly.
|
Sun 26 Feb 2006 12:04:22 PM UTC, comment #3:
> We already support the main SCM CVS, its replacement SVN, and
> the distributed one Arch. The offer should satisfies most
> needs.
As I said in the original submission, I think the usage of Arch is fading out. Most people nowadays use its successor, bazaar, because it is much simpler to use. Moreover, there are even better alternatives, which have learned from the mistakes made by Arch, to provide even simpler and straight-forward version control.
> Adding more SCM the way the previous were added would just be
> plain ugly. Such support should be modular, we cannot clutter
> the interface and database any more and add tons of database
> fields just to do things still the same way.
I'm afraid you got me wrong, then. I wasn't suggesting to add new fields to the database. In fact, almost every field needed is already in the database. The modular approach was just what I had in mind.
> Since there are no major site running Savane interested in
> such features...
If I remember correctly, there have been quite a few support requests on Savannah to integrate the Arch version control system. It's just likely that its successors are wanted, too.
To make this quite clear: all the needed infrastructure for this is already in place, you can today just start right away using e.g. bazaar-ng with Savane. The only thing I'd like to change is to have a nicer support interface in the project's pages for it. We don't need to add menus for each and every SCM, in fact, I discourage us to do so. There should be just one menu item, called "Sources", which would link to the appropriate version control system. Also, we wouldn't need to provide a web browsing mechanism for that, like viewcvs.
> well, it is possible to implement it, but it is harly a
> priority :)
That's why I chose "Priority: Later" for this task ;-)
|
Sun 26 Feb 2006 11:49:50 AM UTC, comment #2:
You may be interested in sr #434, sr #761.
|
Sun 26 Feb 2006 11:37:59 AM UTC, comment #1:
>t's probably time for Savane to be pioneer again and add >official support for those next generation distributed version > control systems.
There is no interest for Gna! in this regard. Gna! purpose is to provide useful tools for Libre Software development, not to test everything available. We already support the main SCM CVS, its replacement SVN, and the distributed one Arch. The offer should satisfies most needs.
>In summary, I think the support should be relatively easy to >integrate into Savane.
Adding more SCM the way the previous were added would just be plain ugly. Such support should be modular, we cannot clutter the interface and database any more and add tons of database fields just to do things still the same way.
Since there are no major site running Savane interested in such features... well, it is possible to implement it, but it is harly a priority :)
|
Sun 26 Feb 2006 11:29:55 AM UTC, original submission:
Savane has been one of the first platforms to support Arch. Nowadays, there are much more distributed/decentralized version control systems, like bazaar-ng, darcs, git, monotone, just to name but a few. At the same time, the development of Arch has stalled (as far as I know) and the usage is probably slowly decreasing.
It's probably time for Savane to be pioneer again and add official support for those next generation distributed version control systems.
While it's already possible to use Savane with those systems, I suggest to add better integration for them.
Currently, one needs to setup the repository in the download area, which is originally designed for file downloads (releases).
As far as I know, every version control system I mentioned above just needs a plain HTTP server for anonymous access. For granting write access to the central repository (thus imitating the CVS or SVN model) the developer needs FTP access to the download area, which is automatically provided to members of a Savane group.
In summary, I think the support should be relatively easy to integrate into Savane.
I suggest to add a new menu item called "Sources" (or maybe "SCM" or "VCS"), to have a generic name. In the project's administration pages users can specify which version control system they use (e.g. a select box with Arch, Bazaar, Darcs, etc.). The public HTTP server could be named source.gna.org (or similar, according to the menu).
We could provide a free text input field (in the admin area) where users can specify their main branch, so that information could be displayed when clicking on the "Source" link in the project's pages. Moreover, we could include generic information on how to access a Darcs repository, or a monotone repository.
Opinions are welcome.
|
Related Recipes:
Savane - Tasks: task #2974, Support for distributed version...