[lm-sensors] svn resync

[lm-sensors] svn resync

[Rudolf Marek]

Hello,

Please can you resync SVN with CVS? I think we can switch after that because the 
commits to both repositories were quite anoying...

Thanks
regards
Rudolf

[lm-sensors] svn resync

[Axel Thimm]

On Wed, May 10, 2006 at 06:57:18PM +0200, Rudolf Marek wrote:
> Please can you resync SVN with CVS? I think we can switch after that
> because the commits to both repositories were quite anoying...

OK. Someone with access to the cvs repo needs to copy it over to the
server (I have no access). Last time either Philip or Jean copied it,
I don't remember anymore. For the migration one needs the RCS files
(foo,v) - anonymous cvs access is not enough.

Just rsync the CVS repo to devel.atrpms.net:/srv/lm-sensors.org/cvs
(or any place else) and I'll do the syncing.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060510/8f901450/attachment.bin

[lm-sensors] svn resync

[Jean Delvare]

Hi all,

[Rudolf Marek]
> > Please can you resync SVN with CVS? I think we can switch after that
> > because the commits to both repositories were quite anoying...

[Axel Thimm]
> OK. Someone with access to the cvs repo needs to copy it over to the
> server (I have no access). Last time either Philip or Jean copied it,
> I don't remember anymore. For the migration one needs the RCS files
> (foo,v) - anonymous cvs access is not enough.
> 
> Just rsync the CVS repo to devel.atrpms.net:/srv/lm-sensors.org/cvs
> (or any place else) and I'll do the syncing.

I have no access to the CVS repository, only Philip Edelbrock has.
Phil, can you please:
* Turn the i2c, lm_sensors and lm_sensors2 modules to read-only.
* Rsync the i2c and lm_sensors2 modules to Axel's server.

I don't think we want to copy the old lm_sensors module to the new
server, that would be a waste of time and energy. I guess we also don't
need the website module, as the new site will be handled differently.
The website module must stay active on the old CVS repository though,
as we will want to maintain the old site until the new one is fully
operational.

-- 
Jean Delvare

[lm-sensors] svn resync

[Philip Edelbrock]

Jean Delvare wrote:
> Hi all,
> 
> [Rudolf Marek]
>>> Please can you resync SVN with CVS? I think we can switch after that
>>> because the commits to both repositories were quite anoying...
> 
> [Axel Thimm]
>> OK. Someone with access to the cvs repo needs to copy it over to the
>> server (I have no access). Last time either Philip or Jean copied it,
>> I don't remember anymore. For the migration one needs the RCS files
>> (foo,v) - anonymous cvs access is not enough.
>>
>> Just rsync the CVS repo to devel.atrpms.net:/srv/lm-sensors.org/cvs
>> (or any place else) and I'll do the syncing.
> 
> I have no access to the CVS repository, only Philip Edelbrock has.
> Phil, can you please:
> * Turn the i2c, lm_sensors and lm_sensors2 modules to read-only.
> * Rsync the i2c and lm_sensors2 modules to Axel's server.
> 
> I don't think we want to copy the old lm_sensors module to the new
> server, that would be a waste of time and energy. I guess we also don't
> need the website module, as the new site will be handled differently.
> The website module must stay active on the old CVS repository though,
> as we will want to maintain the old site until the new one is fully
> operational.
> 

Oops, sorry this email slipped past me.  Thanks, Rudolf, for dropping me 
a note today.

I'm pushing the tar ball up now.


Phil

[lm-sensors] svn resync

[Philip Edelbrock]

Philip Edelbrock wrote:
> 
> 
> Jean Delvare wrote:
>> Hi all,
>>
>> [Rudolf Marek]
>>>> Please can you resync SVN with CVS? I think we can switch after that
>>>> because the commits to both repositories were quite anoying...
>>
>> [Axel Thimm]
>>> OK. Someone with access to the cvs repo needs to copy it over to the
>>> server (I have no access). Last time either Philip or Jean copied it,
>>> I don't remember anymore. For the migration one needs the RCS files
>>> (foo,v) - anonymous cvs access is not enough.
>>>
>>> Just rsync the CVS repo to devel.atrpms.net:/srv/lm-sensors.org/cvs
>>> (or any place else) and I'll do the syncing.
>>
>> I have no access to the CVS repository, only Philip Edelbrock has.
>> Phil, can you please:
>> * Turn the i2c, lm_sensors and lm_sensors2 modules to read-only.
>> * Rsync the i2c and lm_sensors2 modules to Axel's server.
>>
>> I don't think we want to copy the old lm_sensors module to the new
>> server, that would be a waste of time and energy. I guess we also don't
>> need the website module, as the new site will be handled differently.
>> The website module must stay active on the old CVS repository though,
>> as we will want to maintain the old site until the new one is fully
>> operational.
>>
> 
> Oops, sorry this email slipped past me.  Thanks, Rudolf, for dropping me 
> a note today.
> 
> I'm pushing the tar ball up now.
> 
> 

OK, the tar ball is there in my home directory.  I also removed everyone 
from the writers file at cvs.lm-sensors.nu.

Sorry for the delay.


Phil

[lm-sensors] svn resync

[Jean Delvare]

Hi Philip, Axel,

Philip Edelbrock wrote:
> OK, the tar ball is there in my home directory.  I also removed everyone 
> from the writers file at cvs.lm-sensors.nu.

Hm, this turns out to be a problem, as I am now unable to update our
website to mention the migration :( Can't we have different permissions
for the website module? If not, please restore write access for me, so
that I can update the site - I promise I won't write to the i2c and
lm_sensors2 modules ;)

Axel, please proceed with the migration. There's one extra thing I'd
like you to do if possible. All our cvs commits used to begin with the
commiter's short name inside parentheses. This was helping us identify
in the commit mail who had been doing the change. Subversion does
already include the user name in the mails it generates so this
information is now redundant. Can the names be easily removed from the
messages during the migration?

At any rate, after the migration is completed, committers must no more
include their name in commit messages - this is no more needed.

Thanks,
-- 
Jean Delvare

[lm-sensors] svn resync

[Axel Thimm]

Hi,

On Mon, May 29, 2006 at 08:29:48AM +0200, Jean Delvare wrote:
> Philip Edelbrock wrote:
> > OK, the tar ball is there in my home directory.  I also removed everyone 
> > from the writers file at cvs.lm-sensors.nu.

> Axel, please proceed with the migration. There's one extra thing I'd
> like you to do if possible. All our cvs commits used to begin with the
> commiter's short name inside parentheses. This was helping us identify
> in the commit mail who had been doing the change. Subversion does
> already include the user name in the mails it generates so this
> information is now redundant. Can the names be easily removed from the
> messages during the migration?

I'll check and see whether I can easily regex this away.

> At any rate, after the migration is completed, committers must no more
> include their name in commit messages - this is no more needed.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060529/d9fbab44/attachment.bin

[lm-sensors] svn resync

[Axel Thimm]

On Mon, May 29, 2006 at 12:06:12PM +0200, Axel Thimm wrote:
> Hi,
> 
> On Mon, May 29, 2006 at 08:29:48AM +0200, Jean Delvare wrote:
> > Philip Edelbrock wrote:
> > > OK, the tar ball is there in my home directory.  I also removed everyone 
> > > from the writers file at cvs.lm-sensors.nu.
> 
> > Axel, please proceed with the migration. There's one extra thing I'd
> > like you to do if possible. All our cvs commits used to begin with the
> > commiter's short name inside parentheses. This was helping us identify
> > in the commit mail who had been doing the change. Subversion does
> > already include the user name in the mails it generates so this
> > information is now redundant. Can the names be easily removed from the
> > messages during the migration?
> 
> I'll check and see whether I can easily regex this away.

I'm a bit hesitant, look at the simple regex parsing below. Sometimes
it was used for other context, and sometimes even for defering to
another external contributor.

The bulk is Frodo, Khali and mds. Maybe you'd like me to only remove
these or another selected subset? Note also the some *.v files are
binaries like pngs, these should be handled even more carefully. See
also below for a list triggering the matching.

I'd be tempted to not do anything, before creating some inconsistency
that will prop up months later. What do you think?

grep -ra '^@(.*) ' cvs | sed -e's,.*:@(\([^)]*\)) .*,\1,' | sort | uniq -c
     22 amalysh
      1 Aurelien Jarno
      1 Axel Thimm
      7 bobd
      3 bob dougherty
      5 dan
      6 Dan
      9 frodo
   2602 Frodo
      8 Frodo (Frodo
      1 Frodo?ti fix, applied a bit differently (about fan_div and
      1 Frodo?ti fix, applied a bit differently (about fan_div and
      1 Frodo?ti M?kki's patches
      1 Frodo?ti M?kki's patches
      1 Frodo?ti M?kki's patches
      1 Frodo?ti M?kki's patches
      1 Frodo?ti M?kki's patches
      1 Frodo?ti M?kki's patches
      1 Frodo?ti M?kki's patches
      1 Frodo?ti M?kki's patches
      1 Frodo?ti M?kki's patches
      1 Frodo?ti M?kki's patches
      1 Frodo?ti M?kki's patches
      1 Frodo?ti M?kki's patches
      2 Frodo?ti M?kki's semicolon fix.
      1 frood
     11 khali
   2627 Khali
     13 marius
      1 mariusr
   2651 mds
     10 Merlin
      1 MK
     26 MKN
    186 mmh
    120 Phil
      2 ruik
     44 Ruik
      1 Ruik?dez-Sanguino Pe? <jfs@@computer.org>
     14 simon
      7 Simon
      1 smbus.c
      1 stephen
      1 Stephen

# grep -rE '^@\((Frodo|Khali|mds)\) ' cvs|grep Binary
Binary file cvs/lm_sensors2/archive/Attic/mod-19981006.tar.gz,v matches
Binary file cvs/lm_sensors2/archive/Attic/mod-19990118.tar.gz,v matches
Binary file cvs/website/archive/lm78-1.0p2.tgz,v matches
Binary file cvs/website/archive/lm78-1.0p4.tgz,v matches
Binary file cvs/website/archive/lm78-1.2.1.tgz,v matches
Binary file cvs/website/linux-magazin/klm_error.gif,v matches
Binary file cvs/website/linux-magazin/klm_sensors2.gif,v matches
Binary file cvs/website/linux-magazin/lm_sensors.gif,v matches
Binary file cvs/website/linux-magazin/lm_sensors_s.gif,v matches
Binary file cvs/website/linux-magazin/sensors.png,v matches
Binary file cvs/website/linux-magazin/temp_beast.gif,v matches
Binary file cvs/website/decode-dimms.html,v matches
Binary file cvs/website/lm78.jpg,v matches
Binary file cvs/website/tempall.png,v matches
Binary file cvs/website/Attic/osi-logo.gif,v matches
Binary file cvs/website/layers.gif,v matches
Binary file cvs/website/osi-certified-120x100-t.png,v matches

-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060529/c9723429/attachment.bin

[lm-sensors] svn resync

[Jean Delvare]

Axel,

> > > Axel, please proceed with the migration. There's one extra thing I'd
> > > like you to do if possible. All our cvs commits used to begin with the
> > > commiter's short name inside parentheses. This was helping us identify
> > > in the commit mail who had been doing the change. Subversion does
> > > already include the user name in the mails it generates so this
> > > information is now redundant. Can the names be easily removed from the
> > > messages during the migration?
> > 
> > I'll check and see whether I can easily regex this away.
> 
> I'm a bit hesitant, look at the simple regex parsing below. Sometimes
> it was used for other context, and sometimes even for defering to
> another external contributor.
> 
> The bulk is Frodo, Khali and mds. Maybe you'd like me to only remove
> these or another selected subset? Note also the some *.v files are
> binaries like pngs, these should be handled even more carefully. See
> also below for a list triggering the matching.
> 
> I'd be tempted to not do anything, before creating some inconsistency
> that will prop up months later. What do you think?
> 
> grep -ra '^@(.*) ' cvs | sed -e's,.*:@(\([^)]*\)) .*,\1,' | sort | uniq -c
>      22 amalysh
>       1 Aurelien Jarno
>       1 Axel Thimm
>       7 bobd
>       3 bob dougherty
>       5 dan
>       6 Dan
>       9 frodo
>    2602 Frodo
>       8 Frodo (Frodo
>       1 Frodo?ti fix, applied a bit differently (about fan_div and
>       1 Frodo?ti fix, applied a bit differently (about fan_div and
>       1 Frodo?ti M?kki's patches
>       1 Frodo?ti M?kki's patches
>       1 Frodo?ti M?kki's patches
>       1 Frodo?ti M?kki's patches
>       1 Frodo?ti M?kki's patches
>       1 Frodo?ti M?kki's patches
>       1 Frodo?ti M?kki's patches
>       1 Frodo?ti M?kki's patches
>       1 Frodo?ti M?kki's patches
>       1 Frodo?ti M?kki's patches
>       1 Frodo?ti M?kki's patches
>       1 Frodo?ti M?kki's patches
>       2 Frodo?ti M?kki's semicolon fix.
>       1 frood
>      11 khali
>    2627 Khali
>      13 marius
>       1 mariusr
>    2651 mds
>      10 Merlin
>       1 MK
>      26 MKN
>     186 mmh
>     120 Phil
>       2 ruik
>      44 Ruik
>       1 Ruik?dez-Sanguino Pe? <jfs@@computer.org>
>      14 simon
>       7 Simon
>       1 smbus.c
>       1 stephen
>       1 Stephen

There seems to be some trashing with non-ASCII characters? :/

> 
> # grep -rE '^@\((Frodo|Khali|mds)\) ' cvs|grep Binary
> Binary file cvs/lm_sensors2/archive/Attic/mod-19981006.tar.gz,v matches
> Binary file cvs/lm_sensors2/archive/Attic/mod-19990118.tar.gz,v matches
> Binary file cvs/website/archive/lm78-1.0p2.tgz,v matches
> Binary file cvs/website/archive/lm78-1.0p4.tgz,v matches
> Binary file cvs/website/archive/lm78-1.2.1.tgz,v matches
> Binary file cvs/website/linux-magazin/klm_error.gif,v matches
> Binary file cvs/website/linux-magazin/klm_sensors2.gif,v matches
> Binary file cvs/website/linux-magazin/lm_sensors.gif,v matches
> Binary file cvs/website/linux-magazin/lm_sensors_s.gif,v matches
> Binary file cvs/website/linux-magazin/sensors.png,v matches
> Binary file cvs/website/linux-magazin/temp_beast.gif,v matches
> Binary file cvs/website/decode-dimms.html,v matches
> Binary file cvs/website/lm78.jpg,v matches
> Binary file cvs/website/tempall.png,v matches
> Binary file cvs/website/Attic/osi-logo.gif,v matches
> Binary file cvs/website/layers.gif,v matches
> Binary file cvs/website/osi-certified-120x100-t.png,v matches

I'm fine with removing only amalysh, Frodo, khali, mds, mmh, phil and
ruik (all case insensitive) and to exclude binary files. However, if
you don't feel confident, just ignore my request. It's just not that
important so if you think there is any risk, don't do it.

Thanks,
-- 
Jean Delvare

[lm-sensors] svn resync

[Axel Thimm]

Hi,

On Mon, May 29, 2006 at 02:04:17PM +0200, Jean Delvare wrote:
> There seems to be some trashing with non-ASCII characters? :/

CVS has no metainformation about encoding of logs. It can be latin1 or
anything else. The grep I performed was on a utf-8 system.

> I'm fine with removing only amalysh, Frodo, khali, mds, mmh, phil and
> ruik (all case insensitive) and to exclude binary files. However, if
> you don't feel confident, just ignore my request. It's just not that
> important so if you think there is any risk, don't do it.

I made a conversion, please have a look. i2c and lm-sensors are
separated and could indeed have different commit rights as you once
suggested.

The "(author)" bits haven't been touched, I'll retry with the list you
gave. Also we need to discuss how to deal with svn and trac write
access. The idea is to use htdigest for both and not the ssh
accounts. This is because trac doesn't deal with ssh account data and
the account information could be shared between trac and svn (at least
partly). But it also depends on how you'd like to have authorization
handled in lm-sensors vs i2c.

Please don't commit any changes to the svn repo before we settle the
authorization/authentication issues.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060529/a33ad952/attachment.bin

[lm-sensors] svn resync

[Philip Edelbrock]

On May 28, 2006, at 11:29 PM, Jean Delvare wrote:

> Hi Philip, Axel,
>
> Philip Edelbrock wrote:
>> OK, the tar ball is there in my home directory.  I also removed  
>> everyone
>> from the writers file at cvs.lm-sensors.nu.
>
> Hm, this turns out to be a problem, as I am now unable to update our
> website to mention the migration :( Can't we have different  
> permissions
> for the website module? If not, please restore write access for me, so
> that I can update the site - I promise I won't write to the i2c and
> lm_sensors2 modules ;)


OK, I made you a writer again Jean (un: khali).


Phil

[lm-sensors] svn resync

[Jean Delvare]

Hi Axel,

> I made a conversion, please have a look. i2c and lm-sensors are
> separated and could indeed have different commit rights as you once
> suggested.

Looks good to me.

> The "(author)" bits haven't been touched, I'll retry with the list you
> gave. Also we need to discuss how to deal with svn and trac write
> access. The idea is to use htdigest for both and not the ssh
> accounts. This is because trac doesn't deal with ssh account data and
> the account information could be shared between trac and svn (at least
> partly). But it also depends on how you'd like to have authorization
> handled in lm-sensors vs i2c.

We want very limited access to the i2c repository. Basically me, Mark
Hoffman, and that could be it. For the lm-sensors repository we want
more persons to have write access: Rudolf Marek of course, but also new
contributors. We have been quite conservative so far (I take my part of
responsability for this) and it's about time to trust good contributors
more.

As for trac, I'm not really familiar with it, but it looks to me like
users could be different from code contributors, so I'm not certain it
makes sense to have a common authentication method. What are the
benefits of using htdigest for subversion compared to ssh? Are there
drawbacks? I really don't care much as long as it works, so if others
have stronger (motivated) opinions, please speak up.

Thanks,
-- 
Jean Delvare

[lm-sensors] svn resync

[Axel Thimm]

On Tue, May 30, 2006 at 10:16:31AM +0200, Jean Delvare wrote:
> As for trac, I'm not really familiar with it, but it looks to me like
> users could be different from code contributors, so I'm not certain it
> makes sense to have a common authentication method.

Yes, this is true, but contributors should have the same name in both
authentication systems, as for example trac&svn can deduce a ticket
action from a commit. Say khali commits something with a log message
of "Add patch XYZ, this finally fixes #2002.", then trac will
automagically close this ticket with the name of the svn committer.

So every registred committer in svn should also be registred in trac
with the same name. It doesn't have to be the same authentication
method, though, and in fact the authetication databases will be
different, as we will probably have more (non-anonymous) trac users
than committers.

> What are the benefits of using htdigest for subversion compared to
> ssh? Are there drawbacks? I really don't care much as long as it
> works, so if others have stronger (motivated) opinions, please speak
> up.

The benefits of using http+htdigest against svn+ssh are:

o higher performance: ssh needs several new connections with each
  commit/update. You can work around this by using something that
  caches ssh connections like fsh or ssh -M.

o Same URL like anonymous svn checkouts: svn+ssh needs an URI which
  maps exactly the basolute path on the file system,
  e.g.
  svn+ssh://lm-sensors.org/srv/lm-sensors.org/svn/lm-sensors/
  instead of
  http://lm-sensors.org/svn/lm-sensors/

o Priviledge separation: svn+ssh has privileges on the whole repo, you
  can either write to it or not. For having different commiter ACLs
  for i2c vs lm-sensors this is very difficult (you need to add
  another layer of something like userv, see [1])

o account management: Adding a .htdigest line by anyone having an ssh
  account with group lm-sensors (e.g. Jean, Phil, Rudolf and Mark) vs
  creating ssh accounts (which only I can do).

o Pick random usernames for the commits, e.g. khali, frodo
  etc. svn+ssh fixes you to the ssh account name which is again
  dictated by the local account policies.

While it looks like a pile of arguments in favour of http+htdigest,
these aren't blockers. There are also drawbacks:

o http+htdigest stores your password on your local disc,
  ssh+svn+ssh-agent stores it nowhere 

o ssh+svn is more secure than http+htdigest. One could then go
  https+htdigest or https+certificates, but then the setup is equally
  troublesome like for svn+ssh

Again this doesn't cost the world. So from my POV I think
http+htdigest has some little advantages compared to svn+ssh, but it's
up to you what you'll prefer.

(I'm hosting/working with both kinds of repos currently, so both
models work OK)

[1] http://www.chiark.greenend.org.uk/~sgtatham/svn.html

-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060530/5c8c1723/attachment.bin

[lm-sensors] svn resync

[Philip Edelbrock]

OK, I fixed up the Trac database to eliminate the bad characters.   
I'm sure it was some non-utf-8 symbols in the text that went from my  
ticket system to this one which was screwing stuff up.

Alex, I'm not sure how strict you are with permissions, but I made  
the trac.db r/w to the world.  I didn't have the permissions to make  
it owned by Apache.


Phil

[lm-sensors] svn resync

[Axel Thimm]

On Tue, May 30, 2006 at 06:20:46PM -0700, Philip Edelbrock wrote:
> OK, I fixed up the Trac database to eliminate the bad characters.   
> I'm sure it was some non-utf-8 symbols in the text that went from my  
> ticket system to this one which was screwing stuff up.

Thanks!

> Alex, I'm not sure how strict you are with permissions, but I made  
> the trac.db r/w to the world.  I didn't have the permissions to make  
> it owned by Apache.

I fixe dthe permissions. There are other non-lm-sensors accounts on
this system, and I wouldn't want different projects to be able to
accidentially shoot of the neighbor :)

It's group writable, so you (Phil), Jean, Rudolf, Mark and I can
perform any trac administrative action. These will also be the people
that can administer commit rights to i2c and lm-sensors (personally
I'll always defer decisions about commit rights to the others, so
don't really count me in :).
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060531/0b0e5425/attachment.bin