UPDATE!
So, sf.net is completely unsecure now for the web server to write data. So, I have a solution to move the wiki to fd.o and make it work there temporarily.
Unfortunately, we are coming to the limits of using sf.net. We need to start thinking about where to move our project, as it is getting quite large and sf.net is too slow, not reliable for real world web-based needs, and we want svn.
http://inkscape.org/cgi-bin/wiki.pl?ChangingCvsProviders
I will ping the list once the wiki change has happened.
Jon
On Mon, 2005-08-22 at 19:36 -0700, Jon Phillips wrote:
Unfortunately, we are coming to the limits of using sf.net. We need to start thinking about where to move our project, as it is getting quite large and sf.net is too slow, not reliable for real world web-based needs, and we want svn.
I'm experiencing some reservations about SVN, actually. A lot of people have been complaining about branching/tagging/merging in it. Looking into the complaints, a lot of them are really of the "it doesn't work like I'm used to" variety.
However, it does appear to have one really big deficiency -- there's no way to assign a symbolic name to a particular revision number. At all. What they call "tags" are just snapshots whose names you can use for a checkout, but can't specify to SVN in place of revision numbers.
The SVN documentation I've read so far _actually proposes_ grovelling through commit logs _by hand_ to get revision numbers for "tags"... want to merge two branches? You've got to diddle with the log to find the common ancestor revision yourself.
I mean, wow.
-mental
MenTaLguY wrote:
On Mon, 2005-08-22 at 19:36 -0700, Jon Phillips wrote:
Unfortunately, we are coming to the limits of using sf.net. We need to start thinking about where to move our project, as it is getting quite large and sf.net is too slow, not reliable for real world web-based needs, and we want svn.
I'm experiencing some reservations about SVN, actually. A lot of people have been complaining about branching/tagging/merging in it. Looking into the complaints, a lot of them are really of the "it doesn't work like I'm used to" variety.
However, it does appear to have one really big deficiency -- there's no way to assign a symbolic name to a particular revision number. At all. What they call "tags" are just snapshots whose names you can use for a checkout, but can't specify to SVN in place of revision numbers.
The SVN documentation I've read so far _actually proposes_ grovelling through commit logs _by hand_ to get revision numbers for "tags"... want to merge two branches? You've got to diddle with the log to find the common ancestor revision yourself.
I mean, wow.
-mental
The most common practice that I've seen so far is to do an 'svn copy' of the tree to another name. That copy -is- the snapshot of the tree at that given date and revision number...... since everything in SVN is a database of diffs. And since it is diffs, it doesn't take up any extra disk space on the server, so you can do it as often as desired.
Much better than tagging, IMHO.
Bob
On Tue, 2005-08-23 at 11:43 -0500, Bob Jamison wrote:
The most common practice that I've seen so far is to do an 'svn copy' of the tree to another name. That copy -is- the snapshot of the tree at that given date and revision number......
I'm well aware of how tagging/branching works in SVN (that is what the SVN documentation terms such a use of 'svn copy'). The trouble is that it's just a snapshot of the tree; you can't use it as a mnemonic for a particular revision.
I'd rather be able to create meaningful names for revisions rather than have to dig through svn logs looking for the right numbers. Maybe it wouldn't be so bad if SVN didn't force you to explicitly specify revisions so much.
CVS:
cvs update -j HEAD
SVN:
svn log --verbose http://svn.inkscape.org/repos/inkscape/trunk | grep '^r' | head # note topmost version number in log (we'll call it 402)
svn log --verbose --stop-on-copy http://svn.inkscape.org/repos/inkscape/branches/mybranch | grep '^r' | tail # note bottommost version number in log (we'll call it 332)
svn merge -r 332:402 http://svn.inkscape.org/repos/inkscape/trunk
Note that the SVN equivalent only works for first-order branches from HEAD. Merging from the trunk to a second-order or higher branch is even more complex.
Much better than tagging, IMHO.
...if the only thing you'd been using tags for is creating tree snapshots.
Admittedly, maybe nobody else here uses branches.
-mental
MenTaLguY <mental@...3...> writes:
I'm experiencing some reservations about SVN, actually. A lot of people have been complaining about branching/tagging/merging in it. Looking into the complaints, a lot of them are really of the "it doesn't work like I'm used to" variety.
If you don't want to check out a totally different version control system, SVK might be worth a look: http://svk.elixus.org/
To quite from the website: "svk is a decentralized version control system. It uses the Subversion filesystem but provides additional, powerful features."
Cheers, Colin, who sees a VCS war coming though :)
On Wed, 2005-08-24 at 00:29 +0200, Colin Marquardt wrote:
If you don't want to check out a totally different version control system, SVK might be worth a look: http://svk.elixus.org/
SVK looks like it does address _most_ of SVN's deficiencies. At least as far as branching/merging is concerned.
-mental
On Tue, 2005-08-23 at 12:32 -0400, MenTaLguY wrote:
On Mon, 2005-08-22 at 19:36 -0700, Jon Phillips wrote:
Unfortunately, we are coming to the limits of using sf.net. We need to start thinking about where to move our project, as it is getting quite large and sf.net is too slow, not reliable for real world web-based needs, and we want svn.
I'm experiencing some reservations about SVN, actually. A lot of people have been complaining about branching/tagging/merging in it. Looking into the complaints, a lot of them are really of the "it doesn't work like I'm used to" variety.
However, it does appear to have one really big deficiency -- there's no way to assign a symbolic name to a particular revision number. At all. What they call "tags" are just snapshots whose names you can use for a checkout, but can't specify to SVN in place of revision numbers.
The SVN documentation I've read so far _actually proposes_ grovelling through commit logs _by hand_ to get revision numbers for "tags"... want to merge two branches? You've got to diddle with the log to find the common ancestor revision yourself.
I mean, wow.
I entirely agree with you about this. Plus, I find it annoying that you can't get log messages about events that happen to a directory (i.e. added foo, deleted bar) But, on the flip side, I think that subversion is much better than CVS.
--Ted
On Mon, Aug 22, 2005 at 07:36:40PM -0700, Jon Phillips wrote:
UPDATE!
So, sf.net is completely unsecure now for the web server to write data. So, I have a solution to move the wiki to fd.o and make it work there temporarily.
Unfortunately, we are coming to the limits of using sf.net. We need to start thinking about where to move our project, as it is getting quite large and sf.net is too slow, not reliable for real world web-based needs, and we want svn.
http://inkscape.org/cgi-bin/wiki.pl?ChangingCvsProviders
I will ping the list once the wiki change has happened.
Jon and I talked a bit about this yesterday; I mentioned that given our desire for svn (and sf failing to provide it for so long), this issue with the wiki, and the various other issues we've run into, that maybe Inkscape's needs are growing beyond what SourceForge can provide.
Personally, I think right now may not be the best time to make changes in how Inkscape's project infrastructure works, since people are fairly busy, but it may be worth thinking it out.
I'd done a DIY infrastructure in a previous big oss project I ran, and found that while you can do it, it sucks attentions away from the core project. As well, it can create some tension between users who want perfect service, and the sysadmins who want users to not whine. ;-) One of the major reasons why I had Inkscape stick so firmly to SourceForge early on was so that we as a project could focus all of our attention on the code, rather than on mail services, apache, version control, etc. etc.
A possibility is to switch to another third party provider, such as Tigris, Savannah, etc. This could be the best solution, as it may give good capabilities with little work on our part. A risk is that we could be exchanging one set of problems for another. It's worth checking out, though.
However, it's possible we've grown as a project to a point where we *could* take care of providing some or all of our own services. Our needs are becoming increasingly more specific, and our desire to be able to customize things sort of goes beyond what can be done via sourceforge. Going forward I think it's quite likely we are going to need to handle at least some services ourselves. I think as long as we go about it in an organized, pro-active manner, (and can afford the bandwidth) we can get really good results for ourselves.
In WorldForge, we ran our own mailing lists, irc server, CVS, and web. Some lessons I learned in setting this up:
* Never set up a DIY service without including remote backup to at least two other project people that can run the service. If you don't do this, half of your administrative time will be spent recovering from all sorts of misc. disasters.
* Set up a central account system. If for each service you allow it to handle its own account management stuff, then the other half of your time will be spent sorting out account issues. ;-)
* It seems to work well if the sysadmin is not involved in the project. Seems counter-intuitive, but note how solid Inkscape's Jabber service is for us, and its sysadmin is otherwise not involved in Inkscape. Not sure why this is.
* There are more people who have bandwidth to share than there are people who have bandwidth *and* can afford the time to administer machines. The options are most open if you can handle these things independently.
* Shared ownership of a machine seems to work okay in practice. WF pooled money and bought a server, got it configured, and shipped it to the guy that had the bandwidth to host it; we then had multiple people with admin accounts. I think we could do this, too.
* Stay organized. Keep a master services chart listing all the services, who hosts them, who administers them, and who has backups. Otherwise, minor problems become complicated to solve, and major ones can put the project offline.
Bryce
I'm obviously not a programmer, but noticed this and thought it might apply to the conversation.
http://mail.python.org/pipermail/python-dev/2005-August/055372.html
On Tue, 2005-08-23 at 10:39 -0700, Bryce Harrington wrote:
On Mon, Aug 22, 2005 at 07:36:40PM -0700, Jon Phillips wrote:
UPDATE!
So, sf.net is completely unsecure now for the web server to write data. So, I have a solution to move the wiki to fd.o and make it work there temporarily.
Unfortunately, we are coming to the limits of using sf.net. We need to start thinking about where to move our project, as it is getting quite large and sf.net is too slow, not reliable for real world web-based needs, and we want svn.
http://inkscape.org/cgi-bin/wiki.pl?ChangingCvsProviders
I will ping the list once the wiki change has happened.
Jon and I talked a bit about this yesterday; I mentioned that given our desire for svn (and sf failing to provide it for so long), this issue with the wiki, and the various other issues we've run into, that maybe Inkscape's needs are growing beyond what SourceForge can provide.
Personally, I think right now may not be the best time to make changes in how Inkscape's project infrastructure works, since people are fairly busy, but it may be worth thinking it out.
I'd done a DIY infrastructure in a previous big oss project I ran, and found that while you can do it, it sucks attentions away from the core project. As well, it can create some tension between users who want perfect service, and the sysadmins who want users to not whine. ;-) One of the major reasons why I had Inkscape stick so firmly to SourceForge early on was so that we as a project could focus all of our attention on the code, rather than on mail services, apache, version control, etc. etc.
A possibility is to switch to another third party provider, such as Tigris, Savannah, etc. This could be the best solution, as it may give good capabilities with little work on our part. A risk is that we could be exchanging one set of problems for another. It's worth checking out, though.
However, it's possible we've grown as a project to a point where we *could* take care of providing some or all of our own services. Our needs are becoming increasingly more specific, and our desire to be able to customize things sort of goes beyond what can be done via sourceforge. Going forward I think it's quite likely we are going to need to handle at least some services ourselves. I think as long as we go about it in an organized, pro-active manner, (and can afford the bandwidth) we can get really good results for ourselves.
In WorldForge, we ran our own mailing lists, irc server, CVS, and web. Some lessons I learned in setting this up:
Never set up a DIY service without including remote backup to at least two other project people that can run the service. If you don't do this, half of your administrative time will be spent recovering from all sorts of misc. disasters.
Set up a central account system. If for each service you allow it to handle its own account management stuff, then the other half of your time will be spent sorting out account issues. ;-)
It seems to work well if the sysadmin is not involved in the project. Seems counter-intuitive, but note how solid Inkscape's Jabber service is for us, and its sysadmin is otherwise not involved in Inkscape. Not sure why this is.
There are more people who have bandwidth to share than there are people who have bandwidth *and* can afford the time to administer machines. The options are most open if you can handle these things independently.
Shared ownership of a machine seems to work okay in practice. WF pooled money and bought a server, got it configured, and shipped it to the guy that had the bandwidth to host it; we then had multiple people with admin accounts. I think we could do this, too.
Stay organized. Keep a master services chart listing all the services, who hosts them, who administers them, and who has backups. Otherwise, minor problems become complicated to solve, and major ones can put the project offline.
Bryce
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Quoting Jared Thompson Test Account <test@...890...>:
http://mail.python.org/pipermail/python-dev/2005-August/055372.html
I've been meaning to give that one a spin too; thanks for reminding me. I've actually been on a quiet project to review all the currently extant RCSes.
-mental
here are some usage scenarios that he gives:
http://mail.python.org/pipermail/python-dev/2005-August/055376.html
On Thu, 2005-08-25 at 15:14 -0400, mental@...3... wrote:
Quoting Jared Thompson Test Account <test@...890...>:
http://mail.python.org/pipermail/python-dev/2005-August/055372.html
I've been meaning to give that one a spin too; thanks for reminding me. I've actually been on a quiet project to review all the currently extant RCSes.
-mental
mental@...3... dichiarò:
I've been meaning to give that one a spin too; thanks for reminding me. I've actually been on a quiet project to review all the currently extant RCSes.
I'm currently using mercurial. If you want some advice feel free to ask me.
participants (9)
-
unknown＠example.com -
Bob Jamison -
Bryce Harrington -
Colin Marquardt -
Emanuele Aina -
Jared Thompson Test Account -
Jon Phillips -
MenTaLguY -
Ted Gould