According to SF.net's news page, they are finally considering implementing Subversion repositories. Here is the item:
*Subversion Service: * The research, analysis, and support gear-up needed to implement a Subversion service at SourceForge.net is now in progress. As with all SourceForge.net services, extensive analysis and testing must be performed to verify suitable levels of stability and scalability before a service can be rolled-out. We are expecting the initial phases of this effort to last several weeks, to be followed by the implementation of a testing environment which will be used for a live beta test by specific selected projects. Pending successful scalability testing, service details will be finalized and service will be offered to all projects. (Last updated: 2005-03-02 Pacific)
Anyone who is familiar with CVS, but has had an opportunity to use Subversion would never go back. Examples: (a)Try in CVS and SVN, renaming a directory with 100 files in it. No contest. (b) An SVN branch is not a tagging, but an actual branch of a directory tree, with the branch diff'd from the trunk. (c) Commits are 'atomic,' meaning that a commit is not applied if it fails during transfer, but only if it is handled correctly. Very sweet.
It would be nice if Inkscape were one of the "specific selected projects".
Bob
I would certainly support a switch to SVN when sf's SVN hosting is ready, provided we can preserve our revision history from CVS in the switchover.
-mental
On Wed, 2005-03-23 at 16:41 -0500, mental@...3... wrote:
I would certainly support a switch to SVN when sf's SVN hosting is ready, provided we can preserve our revision history from CVS in the switchover.
Yeah, I've had nothig but good experiences with SVN. I support the switch as long as SF.net's use of it is good. Yes, hopefully we can maintain our revision history as well.
How do we get on the list? How do we push for this?
Jon
Quoting Jon Phillips <jon@...235...>:
hopefully we can maintain our revision history as well.
Actually since a lot of folks seem to have neglected adding copyright statements when they add stuff, and also don't always bother to update the ChangeLog, it's kind of critical. We don't have any other complete record of who did what...
This was brought to my attention recently, and is NOT COOL.
For future reference, the ground rules are basically:
1. Anything more than ~10 lines or so warrants a copyright notice. I think four is the lower legal limit for copyright in the US.
2. If you're not comfortable with simply adding your name and copyright dates to an existing copyright/license notice because of wording/etc, don't edit it, but rather insert your own notice above the existing one (this includes public domain dedications!).
3. The copyright notice does need to spell out which license applies. Generally for us this should be GPL 2(+) or a public domain dedication.
4. Don't add a copyright notice on someone else's behalf; the original author needs to do it for themselves, or submit a patch to do it if they don't have commit access
5. As an author of code, assign the copyright to yourself or your employer (as appropriate), not a fictional "Inkscape" organization. Pseudonyms that have a real person behind them are nominally okay though as long as there's a clear identity and it's something you normally use.
-mental
Mental,
I'm not a regular (or otherwise!) contributor at the moment, but I think an example spelt out would help clarify things, particularly in terms of what the copyright notice should say.
Dave.
----- Original Message ----- From: <mental@...3...> To: "Jon Phillips" <jon@...235...> Cc: "Bob Jamison" <rjamison@...357...>; "Inkscape ML" inkscape-devel@lists.sourceforge.net Sent: Wednesday, March 23, 2005 11:36 PM Subject: Re: [Inkscape-devel] sourceforge and subversion
Quoting Jon Phillips <jon@...235...>:
hopefully we can maintain our revision history as well.
Actually since a lot of folks seem to have neglected adding copyright statements when they add stuff, and also don't always bother to update the ChangeLog, it's kind of critical. We don't have any other complete record of who did what...
This was brought to my attention recently, and is NOT COOL.
For future reference, the ground rules are basically:
1. Anything more than ~10 lines or so warrants a copyright notice. I think four is the lower legal limit for copyright in the US.
2. If you're not comfortable with simply adding your name and copyright dates to an existing copyright/license notice because of wording/etc, don't edit it, but rather insert your own notice above the existing one (this includes public domain dedications!).
3. The copyright notice does need to spell out which license applies. Generally for us this should be GPL 2(+) or a public domain dedication.
4. Don't add a copyright notice on someone else's behalf; the original author needs to do it for themselves, or submit a patch to do it if they don't have commit access
5. As an author of code, assign the copyright to yourself or your employer (as appropriate), not a fictional "Inkscape" organization. Pseudonyms that have a real person behind them are nominally okay though as long as there's a clear identity and it's something you normally use.
-mental
------------------------------------------------------- This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register by 3/29 & save $300 http://ads.osdn.com/?ad_idh83&alloc_id%15149&op=ick _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Wed, Mar 23, 2005 at 06:36:06PM -0500, mental@...3... wrote:
Quoting Jon Phillips <jon@...235...>:
hopefully we can maintain our revision history as well.
Actually since a lot of folks seem to have neglected adding copyright statements when they add stuff, and also don't always bother to update the ChangeLog, it's kind of critical. We don't have any other complete record of who did what...
This was brought to my attention recently, and is NOT COOL.
Also, there is a tool called cvs2cl that can collect the changelog info from CVS. I find it too messy for automated changelog generation, but it's a handy tool nonetheless. I will run it on cvs and save a copy of the changelog right now just in case.
For those who don't like writing a changelog entry after they've just done a cvs commit message, it may be worth your while to see if you can derive something from cvs2cl.
For anyone who finds having to comment their changes to be an irritating chore, look at the change processes used by projects like gcc or the kernel or any GNU project; Inkscape's change processes are extremely lightweight in comparison. ;-)
For future reference, the ground rules are basically:
- Anything more than ~10 lines or so warrants a copyright notice.
I think four is the lower legal limit for copyright in the US.
- If you're not comfortable with simply adding your name and
copyright dates to an existing copyright/license notice because of wording/etc, don't edit it, but rather insert your own notice above the existing one (this includes public domain dedications!).
- The copyright notice does need to spell out which license
applies. Generally for us this should be GPL 2(+) or a public domain dedication.
- Don't add a copyright notice on someone else's behalf; the
original author needs to do it for themselves, or submit a patch to do it if they don't have commit access
- As an author of code, assign the copyright to yourself or your
employer (as appropriate), not a fictional "Inkscape" organization. Pseudonyms that have a real person behind them are nominally okay though as long as there's a clear identity and it's something you normally use.
-mental
I agree with all this, with the addition that email addresses should be included (preferrably ones that won't bitrot 5 years hence). In past projects I've gone through a relicensing process that was extremely difficult due to invalid email addresses; we had to toss out a lot of otherwise good material because we could not reach its copyright holder.
Mental, can you add this list to the developer's guide in Wiki?
Bryce
Quoting Bryce Harrington <bryce@...260...>:
Mental, can you add this list to the developer's guide in Wiki?
I've been planning on writing a slightly more complete document on this subject actually. I guess I can stick this in the wiki for now until it gels if you like though...
-mental
By the way, getting these things sorted is kinda something I'd like to specifically address for this release cycle, though I've been reluctant to put that on the actual roadmap.
-mental
On Wed, Mar 23, 2005 at 07:41:14PM -0500, mental@...3... wrote:
By the way, getting these things sorted is kinda something I'd like to specifically address for this release cycle, though I've been reluctant to put that on the actual roadmap.
That's a good idea. Maybe you could put it down in the roadmap for the *next* release cycle, so that at least the tasks are there for others to see. If they happen to get done sooner, so much the better. ;-)
Also, if there are any parts that are rote enough that anyone could do, maybe add them to the janitor's list?
If you're uncertain how we should approach some of the work, I'd be happy to bounce ideas around.
Bryce
On Wed, Mar 23, 2005 at 06:36:06PM -0500, mental@...3... wrote:
- Anything more than ~10 lines or so warrants a copyright notice.
I think four is the lower legal limit for copyright in the US.
This will produce a list of all files touched by a given author, where the number of "+" lines is 10 or greater:
cvs log -wkeescook | egrep '^(Working|^date: )' | awk '{ if ($1 == "date:" && !shown && $9>=10) { shown=1; print file; } if ($1 == "Working") { shown=0; file=$3; } }'
Replace "keescook" with your sourceforge id.
On Wed, 2005-03-23 at 20:09, Kees Cook wrote:
On Wed, Mar 23, 2005 at 06:36:06PM -0500, mental@...3... wrote:
- Anything more than ~10 lines or so warrants a copyright notice.
I think four is the lower legal limit for copyright in the US.
This will produce a list of all files touched by a given author, where the number of "+" lines is 10 or greater:
cvs log -wkeescook | egrep '^(Working|^date: )' | awk '{ if ($1 == "date:" && !shown && $9>=10) { shown=1; print file; } if ($1 == "Working") { shown=0; file=$3; } }'
Replace "keescook" with your sourceforge id.
This is helpful, but of course needs reviewing further since it cannot distinguish between reformatting and actual new/rewritten code.
-mental
On Thu, 2005-03-24 at 10:29 -0500, MenTaLguY wrote:
On Wed, 2005-03-23 at 20:09, Kees Cook wrote:
On Wed, Mar 23, 2005 at 06:36:06PM -0500, mental@...3... wrote:
- Anything more than ~10 lines or so warrants a copyright notice.
I think four is the lower legal limit for copyright in the US.
This will produce a list of all files touched by a given author, where the number of "+" lines is 10 or greater:
cvs log -wkeescook | egrep '^(Working|^date: )' | awk '{ if ($1 == "date:" && !shown && $9>=10) { shown=1; print file; } if ($1 == "Working") { shown=0; file=$3; } }'
Replace "keescook" with your sourceforge id.
Man, that one liner is nuts! Crazy! I went through and added some copyright statements to what I've worked on, but I know I've forgotten some. Thanks for the one liner Kees, that will help...hahaaha
Jon
On Wed, Mar 23, 2005 at 03:08:35PM -0600, Bob Jamison wrote:
According to SF.net's news page, they are finally considering implementing Subversion repositories.
Anyone who is familiar with CVS, but has had an opportunity to use Subversion would never go back. Examples: (a)Try in CVS and SVN, renaming a directory with 100 files in it. No contest. (b) An SVN branch is not a tagging, but an actual branch of a directory tree, with the branch diff'd from the trunk. (c) Commits are 'atomic,' meaning that a commit is not applied if it fails during transfer, but only if it is handled correctly. Very sweet.
Hopefully it will also be faster. I've learned to deal with the other CVS iniquities but there's no way to really get around the performance problems.
It would be nice if Inkscape were one of the "specific selected projects".
Bob, can you follow up with investigating how we could get onto that list?
In fact, early on in the project before SF committed to adding Subversion, I had explored the feasibility of us doing our own VCS hosting. That investigation stopped only because we'd heard SF was implementing this. ;-)
Also, does anyone have reservations about making a wholesale switch over to Subversion with the main codebase? I have used Subversion previously and found the commands to be analogous enough to CVS that it didn't take long to learn. The main concern I would have is instability/bugs in their implementation. It sounds like they're going to be testing it pretty heavily though, and svn's been around long enough that the software itself should be stable compared with cvs.
Bryce
Bryce Harrington wrote:
Hopefully it will also be faster. I've learned to deal with the other CVS iniquities but there's no way to really get around the performance problems.
SVN is chatty... but since the directory is considered as a whole, and not a set of loose files, it is basically sending a single big diff instead of a collection of small ones. Also, your client will have zip and ssl built-in. Oh, and it does -binary diffs-. So it won't always need to send a complete copy of a binary file the way CVS does. I think that maybe per-text-file it might be slower, but the higher level optimizations should make it faster. And it works on port 80, for firewalled people.
It would be nice if Inkscape were one of the "specific selected projects".
Bob, can you follow up with investigating how we could get onto that list?
I'll zag an email to someone.
Also, does anyone have reservations about making a wholesale switch over to Subversion with the main codebase? I have used Subversion previously and found the commands to be analogous enough to CVS that it didn't take long to learn.
There are conversion tools that will allow the mapping of CVS tags/branches/etc into their SVN equivalents.
The main concern I would have is instability/bugs in their implementation. It sounds like they're going to be testing it pretty heavily though, and svn's been around long enough that the software itself should be stable compared with cvs.
We used it in a development environment for my day job with > 60 MB of source and resources, no problem. And that was two years ago. The only problems in pre-1.0 versions was that the database schema changed occasionally, so upgrading the server was a touchy problem. The devs have promised to not change it again until the next major version.
Bob
On Wed, Mar 23, 2005 at 04:16:53PM -0600, Bob Jamison wrote:
Bryce Harrington wrote:
Hopefully it will also be faster. I've learned to deal with the other CVS iniquities but there's no way to really get around the performance problems.
SVN is chatty... but since the directory is considered as a whole, and not a set of loose files, it is basically sending a single big diff instead of a collection of small ones. Also, your client will have zip and ssl built-in. Oh, and it does -binary diffs-. So it won't always need to send a complete copy of a binary file the way CVS does. I think that maybe per-text-file it might be slower, but the higher level optimizations should make it faster. And it works on port 80, for firewalled people.
Well, I suspect the main driver here will be the hardware, particularly the quality of it's I/O bus and harddrive speed. Even the best processor and network capabilities can be hamstrung by poorly sized I/O. For large scale systems, that also happens to be pretty expensive to do right, and too easy to cut some corners on...
It would be nice if Inkscape were one of the "specific selected projects".
Bob, can you follow up with investigating how we could get onto that list?
I'll zag an email to someone.
Great, thanks.
The main concern I would have is instability/bugs in their implementation. It sounds like they're going to be testing it pretty heavily though, and svn's been around long enough that the software itself should be stable compared with cvs.
We used it in a development environment for my day job with > 60 MB of source and resources, no problem. And that was two years ago. The only problems in pre-1.0 versions was that the database schema changed occasionally, so upgrading the server was a touchy problem. The devs have promised to not change it again until the next major version.
*Nod* I've also seen it successfully implemented, but then I've also seen CVS implemented much more successfully than at SourceForge... ;-)
Bryce
participants (7)
-
unknown＠example.com -
Bob Jamison -
Bryce Harrington -
David Bower -
Jon Phillips -
Kees Cook -
MenTaLguY