6:08 a.m.
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
6:41 a.m.
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
7:15 a.m.
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
8:36 a.m.
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
8:43 a.m.
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(a)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_id149&op=ick
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
9:21 a.m.
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:
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
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
9:39 a.m.
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
9:41 a.m.
New subject: copyright bits
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
10:13 a.m.
New subject: copyright bits
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
10:09 a.m.
On Wed, Mar 23, 2005 at 06:36:06PM -0500, mental@...3... wrote:
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.
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.
--
Kees Cook @outflux.net
12:29 a.m.
On Wed, 2005-03-23 at 20:09, Kees Cook wrote:
On Wed, Mar 23, 2005 at 06:36:06PM -0500, mental@...3... wrote:
> 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.
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
6:34 a.m.
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:
> > 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.
>
> 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
--
Jon Phillips
USA PH 510.499.0894
jon@...235...
http://www.rejon.org
Inkscape (http://inkscape.org)
Open Clip Art Library (www.openclipart.org)
CVS Book (http://cvsbook.ucsd.edu)
Scale Journal (http://scale.ucsd.edu)
6:46 a.m.
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
7:16 a.m.
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
9:06 a.m.
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
6575
days inactive
6576
days old
inkscape-devel@lists.inkscape.org
14 comments
7 participants
participants (7)
-
unknown＠example.com -
Bob Jamison -
Bryce Harrington -
David Bower -
Jon Phillips -
Kees Cook -
MenTaLguY