[lm-sensors] Checking out and comitting to the libsensors-3.x branch

[lm-sensors] Checking out and comitting to the libsensors-3.x branch

[Hans de Goede]

Hi,

I've been really busy lately with Fedora related "work", but I hope to find the 
time soon to start working on the dyn chip support. Most of the code is already 
tehre for the 2.x branch (written by my students). ANd my initial testing was good.

This leads me to the following questions:
1) What cmdline magic must I pass to svn to get the 3.x branch when checking
    out?
2) Do I need any cmdline magic to make sure a commit goes to the 3.x branch?
    (I've bad experiences with this with CVS, where a commit would go to the
     default branch even though I checkout another)
3) Is it ok for me to just start committing this, or should I post it for
    review here first?

Thanks & Regards,

Hans



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Checking out and comitting to the libsensors-3.x

[Jean Delvare]

Hi Hans,

On Mon, 02 Apr 2007 10:17:41 +0200, Hans de Goede wrote:
> I've been really busy lately with Fedora related "work", but I hope to find the 
> time soon to start working on the dyn chip support. Most of the code is already 
> tehre for the 2.x branch (written by my students). ANd my initial testing was good.
> 
> This leads me to the following questions:
> 1) What cmdline magic must I pass to svn to get the 3.x branch when checking
>     out?

svn checkout http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0

> 2) Do I need any cmdline magic to make sure a commit goes to the 3.x branch?
>     (I've bad experiences with this with CVS, where a commit would go to the
>      default branch even though I checkout another)

I've never done that, so I can't say for sure, but I think svn will
remember what branch you checked out from and you don't need to add any
parameter. Mark, can you please confirm this?

> 3) Is it ok for me to just start committing this, or should I post it for
>     review here first?

I am usually committing directly, except when I am not sure myself that
this is the right thing to do, in which case I post on the list first,
and then sometimes commit the change, sometimes not. So it's up to you,
for changes you are sure of or that have already been discussed, just
commit them, and use the list if you think something needs to be
discussed first. Remember, the whole idea of a separate 3.0.0 branch is
that you can put all your changes there quickly.

Before you start really working on the 3.0.0 branch, we should sync it
with the current trunk. Mark created the 3.0.0 branch quite some time
ago, many fixes have gone into trunk since then, and I would hate to
lose them. I don't know how this is done though. Mark, can you please
take care of it? Maybe just kill the branch and recreate it?

I also don't know how we are going to handle the later trunk changes,
once 3.0.0 development is in progress. Some changes won't apply to the
3.0.0 branch (e.g. adding support for a new chip in libsensors) but
many will.

Once real work starts on this branch, it should be documented on our
Download page how to get the code, if we want testers. It would also be
convenient to have nightly snapshots as we do for the trunk version.
Axel, can this be done?

Thanks,
-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Checking out and comitting to the libsensors-3.x

[Axel Thimm]

[-- Attachment #1.1: Type: text/plain, Size: 3670 bytes --]

Hi,

On Mon, Apr 02, 2007 at 01:36:49PM +0200, Jean Delvare wrote:
> On Mon, 02 Apr 2007 10:17:41 +0200, Hans de Goede wrote:
> > I've been really busy lately with Fedora related "work", but I hope to find the 
> > time soon to start working on the dyn chip support. Most of the code is already 
> > tehre for the 2.x branch (written by my students). ANd my initial testing was good.
> > 
> > This leads me to the following questions:
> > 1) What cmdline magic must I pass to svn to get the 3.x branch when checking
> >     out?
> 
> svn checkout http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0

Hans, you should checkout the svnbook that you've been pointed
at. There is a section that explains svn for CVS people.

Branches and tags in svn are really nothing more than a folder. You
can argue that there are no branches and tags at all, if you
like. Which makes it quite easy to place your own organization of
things on top of it. You could rename "trunk" to "head" or remove it
altogether, if it doesn't fit your developing model.

svn is quite flexible. The basic operations concerning branches and
tags are simple copy operations.

> > 2) Do I need any cmdline magic to make sure a commit goes to the 3.x branch?
> >     (I've bad experiences with this with CVS, where a commit would go to the
> >      default branch even though I checkout another)
> 
> I've never done that, so I can't say for sure, but I think svn will
> remember what branch you checked out from and you don't need to add any
> parameter. Mark, can you please confirm this?

See above. It is just a folder. And svn will remember what folder you
checked out like CVS does.

> > 3) Is it ok for me to just start committing this, or should I post it for
> >     review here first?
> 
> I am usually committing directly, except when I am not sure myself that
> this is the right thing to do, in which case I post on the list first,
> and then sometimes commit the change, sometimes not. So it's up to you,
> for changes you are sure of or that have already been discussed, just
> commit them, and use the list if you think something needs to be
> discussed first. Remember, the whole idea of a separate 3.0.0 branch is
> that you can put all your changes there quickly.
> 
> Before you start really working on the 3.0.0 branch, we should sync it
> with the current trunk. Mark created the 3.0.0 branch quite some time
> ago, many fixes have gone into trunk since then, and I would hate to
> lose them. I don't know how this is done though. Mark, can you please
> take care of it? Maybe just kill the branch and recreate it?

Why not define that "trunk := 3.x.x"? And only branch near a release?
Or do we need two different development areas?

Hans, whioch svn you can also create your very personal branch and
start playing in there. E.g.

http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0-hans

Once you're comfortable you can then either nuke it or merge back any
production commits back to the main branch or trunk.

> I also don't know how we are going to handle the later trunk changes,
> once 3.0.0 development is in progress. Some changes won't apply to the
> 3.0.0 branch (e.g. adding support for a new chip in libsensors) but
> many will.
> 
> Once real work starts on this branch, it should be documented on our
> Download page how to get the code, if we want testers. It would also be
> convenient to have nightly snapshots as we do for the trunk version.
> Axel, can this be done?

Of course. Just say so, once you consider snapshoting to make sense.
-- 
Axel.Thimm at ATrpms.net

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Checking out and comitting to the libsensors-3.x

[Mark M. Hoffman]

Hi everyone:

> On Mon, 02 Apr 2007 10:17:41 +0200, Hans de Goede wrote:
> > I've been really busy lately with Fedora related "work", but I hope to find the 
> > time soon to start working on the dyn chip support. Most of the code is already 
> > tehre for the 2.x branch (written by my students). ANd my initial testing was good.
> > 
> > This leads me to the following questions:
> > 1) What cmdline magic must I pass to svn to get the 3.x branch when checking
> >     out?

* Jean Delvare <khali@linux-fr.org> [2007-04-02 13:36:49 +0200]:
> svn checkout http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0

Correct.

> > 2) Do I need any cmdline magic to make sure a commit goes to the 3.x branch?
> >     (I've bad experiences with this with CVS, where a commit would go to the
> >      default branch even though I checkout another)
> 
> I've never done that, so I can't say for sure, but I think svn will
> remember what branch you checked out from and you don't need to add any
> parameter. Mark, can you please confirm this?

Correct.

> > 3) Is it ok for me to just start committing this, or should I post it for
> >     review here first?
> 
> I am usually committing directly, except when I am not sure myself that
> this is the right thing to do, in which case I post on the list first,
> and then sometimes commit the change, sometimes not. So it's up to you,
> for changes you are sure of or that have already been discussed, just
> commit them, and use the list if you think something needs to be
> discussed first. Remember, the whole idea of a separate 3.0.0 branch is
> that you can put all your changes there quickly.
> 
> Before you start really working on the 3.0.0 branch, we should sync it
> with the current trunk. Mark created the 3.0.0 branch quite some time
> ago, many fixes have gone into trunk since then, and I would hate to
> lose them. I don't know how this is done though. Mark, can you please
> take care of it? Maybe just kill the branch and recreate it?

I synced up the 3.0.0 branch this morning.  I would have just recreated it as
you suggest, except that I have 3 local copies of it, each with changes that
I haven't committed yet.  Merging it up to date was easier for me.

Here's what I did:

1. From which revision was the branch created?  The stop-on-copy arg tells svn
to show me logs going back to when the branch was created.  (A branch is nothing
more than a directory copy.)

	$ cd <working copy of 3.0.0 branch>
	$ svn log --stop-on-copy

2. What's the most recent revision on the trunk?

	$ cd <working copy of trunk>
	$ svn up

3. A merge is: find the differences between an old revision and a newer one,
apply those differences to the target branch.  (I specify the target branch
implicity in the following command, it's the branch of the CWD.)

	$ cd <working copy of 3.0.0 branch>
	$ svn merge -r 4303:4355 http://lm-sensors.org/svn/lm-sensors/trunk

> I also don't know how we are going to handle the later trunk changes,
> once 3.0.0 development is in progress. Some changes won't apply to the
> 3.0.0 branch (e.g. adding support for a new chip in libsensors) but
> many will.

IMPORTANT NOTE: next time we want to merge trunk changes out to the 3.0.0
branch, the merge command will be slightly different.  We must not use r4303
as the starting point, but rather r4355; otherwise we might duplicate some
changes.  So it is important to remember that we're synced up to r4355.  The
convention is to record that information in the commit log when the merge is
committed (which I did.)

If there are changes to trunk that don't make sense in the branch, then we can
handle that by "anti" cherry-picking them.  E.g. if r4360 is such a change,
we'll sync r4355:r4359 and then again r4361:whatever.

> Once real work starts on this branch, it should be documented on our
> Download page how to get the code, if we want testers. It would also be
> convenient to have nightly snapshots as we do for the trunk version.
> Axel, can this be done?

I don't think this is wanted just yet.  It's a good idea for later though.

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Checking out and comitting to the libsensors-3.x

[Jean Delvare]

Hi Axel,

On Mon, 2 Apr 2007 14:01:41 +0200, Axel Thimm wrote:
> Why not define that "trunk := 3.x.x"? And only branch near a release?
> Or do we need two different development areas?

We need two different development areas. We wouldn't have bothered with
a separate branch otherwise, mind you ;)

BTW, lm-sensors.org's trac looks broken to me, it spits python errors
at me for every page but the main page.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Checking out and comitting to the libsensors-3.x

[Axel Thimm]

[-- Attachment #1.1: Type: text/plain, Size: 316 bytes --]

Hi,

On Wed, Apr 04, 2007 at 09:29:10PM +0200, Jean Delvare wrote:
> BTW, lm-sensors.org's trac looks broken to me, it spits python errors
> at me for every page but the main page.

That's bad, can you give me a failing URL? I can't seem to be
(un)lucky enough to find one. :/
-- 
Axel.Thimm at ATrpms.net

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Checking out and comitting to the libsensors-3.x

[Jean Delvare]

Hi Axel,

Sorry for the delay.

On Wed, 4 Apr 2007 21:43:17 +0200, Axel Thimm wrote:
> Hi,
> 
> On Wed, Apr 04, 2007 at 09:29:10PM +0200, Jean Delvare wrote:
> > BTW, lm-sensors.org's trac looks broken to me, it spits python errors
> > at me for every page but the main page.
> 
> That's bad, can you give me a failing URL? I can't seem to be
> (un)lucky enough to find one. :/

http://www.lm-sensors.org/wiki/Devices

Oops…
Trac detected an internal error:

If you think this really should work and you can reproduce it, you should consider reporting this problem to the Trac team.

Go to http://trac.edgewall.org/ and create a new ticket where you describe the problem, how to reproduce it. Don't forget to include the Python traceback found below.

TracGuide — The Trac User and Administration Guide
Python Traceback

Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 387, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 191, in dispatch
    chosen_handler = self._pre_process_request(req, chosen_handler)
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 263, in _pre_process_request
    chosen_handler = f.pre_process_request(req, chosen_handler)
  File "/usr/lib/python2.4/site-packages/trac/versioncontrol/api.py", line 73, in pre_process_request
    self.get_repository(req.authname) # triggers a sync if applicable
  File "/usr/lib/python2.4/site-packages/trac/versioncontrol/api.py", line 101, in get_repository
    repos = self._connector.get_repository(rtype, rdir, authname)
  File "/usr/lib/python2.4/site-packages/trac/versioncontrol/svn_fs.py", line 259, in get_repository
    repos = SubversionRepository(dir, None, self.log)
  File "/usr/lib/python2.4/site-packages/trac/versioncontrol/svn_fs.py", line 281, in __init__
    self.pool = Pool()
  File "/usr/lib/python2.4/site-packages/trac/versioncontrol/svn_fs.py", line 158, in __init__
    self._pool = core.svn_pool_create(self._parent_pool())
  File "/usr/lib64/python2.4/site-packages/svn/core.py", line 177, in svn_pool_create
    return Pool(parent_pool)
  File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 1080, in svn_pool_create
    return apply(_core.svn_pool_create, args)
  File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 3081, in _wrap
    obj.set_parent_pool(self)
  File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 2994, in set_parent_pool
    self._parent_pool = parent_pool or application_pool
  File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 2982, in <lambda>
    __setattr__ = lambda self, name, value: _swig_setattr(self, apr_pool_t, name, value)
  File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 22, in _swig_setattr
    return _swig_setattr_nondynamic(self,class_type,name,value,0)
  File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 17, in _swig_setattr_nondynamic
    self.__dict__[name] = value
RuntimeError: instance.__dict__ not accessible in restricted mode

It's an intermittent error, sometimes I get it, sometimes I don't.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Checking out and comitting to the libsensors-3.x

[Axel Thimm]

[-- Attachment #1.1: Type: text/plain, Size: 3552 bytes --]

Hi,

On Thu, Apr 05, 2007 at 10:15:04PM +0200, Jean Delvare wrote:
> Hi Axel,
> 
> Sorry for the delay.
> 
> On Wed, 4 Apr 2007 21:43:17 +0200, Axel Thimm wrote:
> > Hi,
> > 
> > On Wed, Apr 04, 2007 at 09:29:10PM +0200, Jean Delvare wrote:
> > > BTW, lm-sensors.org's trac looks broken to me, it spits python errors
> > > at me for every page but the main page.
> > 
> > That's bad, can you give me a failing URL? I can't seem to be
> > (un)lucky enough to find one. :/
> 
> http://www.lm-sensors.org/wiki/Devices
> 
> Oops…
> Trac detected an internal error:
> 
> If you think this really should work and you can reproduce it, you should consider reporting this problem to the Trac team.
> 
> Go to http://trac.edgewall.org/ and create a new ticket where you describe the problem, how to reproduce it. Don't forget to include the Python traceback found below.
> 
> TracGuide — The Trac User and Administration Guide
> Python Traceback
> 
> Traceback (most recent call last):
>   File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 387, in dispatch_request
>     dispatcher.dispatch(req)
>   File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 191, in dispatch
>     chosen_handler = self._pre_process_request(req, chosen_handler)
>   File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 263, in _pre_process_request
>     chosen_handler = f.pre_process_request(req, chosen_handler)
>   File "/usr/lib/python2.4/site-packages/trac/versioncontrol/api.py", line 73, in pre_process_request
>     self.get_repository(req.authname) # triggers a sync if applicable
>   File "/usr/lib/python2.4/site-packages/trac/versioncontrol/api.py", line 101, in get_repository
>     repos = self._connector.get_repository(rtype, rdir, authname)
>   File "/usr/lib/python2.4/site-packages/trac/versioncontrol/svn_fs.py", line 259, in get_repository
>     repos = SubversionRepository(dir, None, self.log)
>   File "/usr/lib/python2.4/site-packages/trac/versioncontrol/svn_fs.py", line 281, in __init__
>     self.pool = Pool()
>   File "/usr/lib/python2.4/site-packages/trac/versioncontrol/svn_fs.py", line 158, in __init__
>     self._pool = core.svn_pool_create(self._parent_pool())
>   File "/usr/lib64/python2.4/site-packages/svn/core.py", line 177, in svn_pool_create
>     return Pool(parent_pool)
>   File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 1080, in svn_pool_create
>     return apply(_core.svn_pool_create, args)
>   File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 3081, in _wrap
>     obj.set_parent_pool(self)
>   File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 2994, in set_parent_pool
>     self._parent_pool = parent_pool or application_pool
>   File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 2982, in <lambda>
>     __setattr__ = lambda self, name, value: _swig_setattr(self, apr_pool_t, name, value)
>   File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 22, in _swig_setattr
>     return _swig_setattr_nondynamic(self,class_type,name,value,0)
>   File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 17, in _swig_setattr_nondynamic
>     self.__dict__[name] = value
> RuntimeError: instance.__dict__ not accessible in restricted mode
> 
> It's an intermittent error, sometimes I get it, sometimes I don't.

That's the errors one loves. Looks like it's a known issue for more
than a year:

http://trac.edgewall.org/ticket/3371

-- 
Axel.Thimm at ATrpms.net

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Checking out and comitting to the libsensors-3.x

[Jean Delvare]

Hi Mark,

On Tue, 3 Apr 2007 09:15:28 -0400, Mark M. Hoffman wrote:
> Hi everyone:
> 
> > On Mon, 02 Apr 2007 10:17:41 +0200, Hans de Goede wrote:
> > > I've been really busy lately with Fedora related "work", but I hope to find the 
> > > time soon to start working on the dyn chip support. Most of the code is already 
> > > tehre for the 2.x branch (written by my students). ANd my initial testing was good.
> > > 
> > > This leads me to the following questions:
> > > 1) What cmdline magic must I pass to svn to get the 3.x branch when checking
> > >     out?
> 
> * Jean Delvare <khali@linux-fr.org> [2007-04-02 13:36:49 +0200]:
> > svn checkout http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0
> 
> Correct.
> 
> > > 2) Do I need any cmdline magic to make sure a commit goes to the 3.x branch?
> > >     (I've bad experiences with this with CVS, where a commit would go to the
> > >      default branch even though I checkout another)
> > 
> > I've never done that, so I can't say for sure, but I think svn will
> > remember what branch you checked out from and you don't need to add any
> > parameter. Mark, can you please confirm this?
> 
> Correct.
> 
> > > 3) Is it ok for me to just start committing this, or should I post it for
> > >     review here first?
> > 
> > I am usually committing directly, except when I am not sure myself that
> > this is the right thing to do, in which case I post on the list first,
> > and then sometimes commit the change, sometimes not. So it's up to you,
> > for changes you are sure of or that have already been discussed, just
> > commit them, and use the list if you think something needs to be
> > discussed first. Remember, the whole idea of a separate 3.0.0 branch is
> > that you can put all your changes there quickly.
> > 
> > Before you start really working on the 3.0.0 branch, we should sync it
> > with the current trunk. Mark created the 3.0.0 branch quite some time
> > ago, many fixes have gone into trunk since then, and I would hate to
> > lose them. I don't know how this is done though. Mark, can you please
> > take care of it? Maybe just kill the branch and recreate it?
> 
> I synced up the 3.0.0 branch this morning.  I would have just recreated it as
> you suggest, except that I have 3 local copies of it, each with changes that
> I haven't committed yet.  Merging it up to date was easier for me.

OK, no problem.

> Here's what I did:
> 
> 1. From which revision was the branch created?  The stop-on-copy arg tells svn
> to show me logs going back to when the branch was created.  (A branch is nothing
> more than a directory copy.)
> 
> 	$ cd <working copy of 3.0.0 branch>
> 	$ svn log --stop-on-copy
> 
> 2. What's the most recent revision on the trunk?
> 
> 	$ cd <working copy of trunk>
> 	$ svn up
> 
> 3. A merge is: find the differences between an old revision and a newer one,
> apply those differences to the target branch.  (I specify the target branch
> implicity in the following command, it's the branch of the CWD.)
> 
> 	$ cd <working copy of 3.0.0 branch>
> 	$ svn merge -r 4303:4355 http://lm-sensors.org/svn/lm-sensors/trunk

Thanks for the lesson, I'm bookmarking this for later.

What would have happened if some of the changes from trunk had been
conflicting with changes in branch 3.0.0?

It seems that we lose the history of changes when merging a branch, the
logs only show the merge and not the individual log messages. Is this
expected? I guess so :(

> > I also don't know how we are going to handle the later trunk changes,
> > once 3.0.0 development is in progress. Some changes won't apply to the
> > 3.0.0 branch (e.g. adding support for a new chip in libsensors) but
> > many will.
> 
> IMPORTANT NOTE: next time we want to merge trunk changes out to the 3.0.0
> branch, the merge command will be slightly different.  We must not use r4303
> as the starting point, but rather r4355; otherwise we might duplicate some
> changes.  So it is important to remember that we're synced up to r4355.  The
> convention is to record that information in the commit log when the merge is
> committed (which I did.)
> 
> If there are changes to trunk that don't make sense in the branch, then we can
> handle that by "anti" cherry-picking them.  E.g. if r4360 is such a change,
> we'll sync r4355:r4359 and then again r4361:whatever.

Another method would be to commit to both branches in parallel when a
given change belongs to both branches. Looking at the changes you just
merged, it seems that only a small amount of these were really needed
in 3.0.0. All the changes to the kernel drivers, their documentation,
lib/chips.*, prog/sensors/chips.* and sensors.conf.eg are for 2.10.x
only. This doesn't leave that many areas where changes really need to
be merged.

Also, parallel commit would have the benefit that we have a better
history, and no merge delay. Opinion anyone?

Thanks,
-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Checking out and comitting to the libsensors-3.x

[Axel Thimm]

[-- Attachment #1.1: Type: text/plain, Size: 1312 bytes --]

On Sun, Apr 08, 2007 at 10:14:30AM +0200, Jean Delvare wrote:
> > 3. A merge is: find the differences between an old revision and a newer one,
> > apply those differences to the target branch.  (I specify the target branch
> > implicity in the following command, it's the branch of the CWD.)
> > 
> > 	$ cd <working copy of 3.0.0 branch>
> > 	$ svn merge -r 4303:4355 http://lm-sensors.org/svn/lm-sensors/trunk
> 
> What would have happened if some of the changes from trunk had been
> conflicting with changes in branch 3.0.0?
> 
> It seems that we lose the history of changes when merging a branch, the
> logs only show the merge and not the individual log messages. Is this
> expected? I guess so :(

The problem is if you have two branches A and B and merge/copy over
parts of B onto A, then a file in A has semantically two histories,
one for the per-merge copy in A and one for the pre-merge copy in
B. Since the history of the B copy remains in B and also since the
true history of A != B, there isn't much choice. It is also a conflict
of interests: The developer of branch A would like to see what changed
from his POV, the one in B from his own.

But you do get a marker for copies or merges that you can follow to
fork off A's history into B's.
-- 
Axel.Thimm at ATrpms.net

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Checking out and comitting to the libsensors-3.x

[Jean Delvare]

Hi Axel,

On Sun, 8 Apr 2007 10:33:48 +0200, Axel Thimm wrote:
> On Sun, Apr 08, 2007 at 10:14:30AM +0200, Jean Delvare wrote:
> > It seems that we lose the history of changes when merging a branch, the
> > logs only show the merge and not the individual log messages. Is this
> > expected? I guess so :(
> 
> The problem is if you have two branches A and B and merge/copy over
> parts of B onto A, then a file in A has semantically two histories,
> one for the per-merge copy in A and one for the pre-merge copy in
> B. Since the history of the B copy remains in B and also since the
> true history of A != B, there isn't much choice.

Well, some source code management tools do handle it just fine, git for
example. So it's technically feasable.

>                                                  It is also a conflict
> of interests: The developer of branch A would like to see what changed
> from his POV, the one in B from his own.

Not necessarily. In my case, my wish is exactly the opposite, I would
like to have an history of all the changes, whether they originate from
my branch or not.

> But you do get a marker for copies or merges that you can follow to
> fork off A's history into B's.

True, but that's hardly convenient if merges are frequent and/or if the
number of branches is important. I start understanding why people
working with many branches don't even consider Subversion.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Checking out and comitting to the libsensors-3.x

[Jean Delvare]

Hi Axel,

On Thu, 5 Apr 2007 22:31:59 +0200, Axel Thimm wrote:
> On Thu, Apr 05, 2007 at 10:15:04PM +0200, Jean Delvare wrote:
> > http://www.lm-sensors.org/wiki/Devices
> > 
> > Oops…
> > Trac detected an internal error:
> > 
> > If you think this really should work and you can reproduce it, you should consider reporting this problem to the Trac team.
> > 
> > Go to http://trac.edgewall.org/ and create a new ticket where you describe the problem, how to reproduce it. Don't forget to include the Python traceback found below.
> > 
> > TracGuide — The Trac User and Administration Guide
> > Python Traceback
> > 
> > Traceback (most recent call last):
> >   File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 387, in dispatch_request
> >     dispatcher.dispatch(req)
> >   File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 191, in dispatch
> >     chosen_handler = self._pre_process_request(req, chosen_handler)
> >   File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 263, in _pre_process_request
> >     chosen_handler = f.pre_process_request(req, chosen_handler)
> >   File "/usr/lib/python2.4/site-packages/trac/versioncontrol/api.py", line 73, in pre_process_request
> >     self.get_repository(req.authname) # triggers a sync if applicable
> >   File "/usr/lib/python2.4/site-packages/trac/versioncontrol/api.py", line 101, in get_repository
> >     repos = self._connector.get_repository(rtype, rdir, authname)
> >   File "/usr/lib/python2.4/site-packages/trac/versioncontrol/svn_fs.py", line 259, in get_repository
> >     repos = SubversionRepository(dir, None, self.log)
> >   File "/usr/lib/python2.4/site-packages/trac/versioncontrol/svn_fs.py", line 281, in __init__
> >     self.pool = Pool()
> >   File "/usr/lib/python2.4/site-packages/trac/versioncontrol/svn_fs.py", line 158, in __init__
> >     self._pool = core.svn_pool_create(self._parent_pool())
> >   File "/usr/lib64/python2.4/site-packages/svn/core.py", line 177, in svn_pool_create
> >     return Pool(parent_pool)
> >   File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 1080, in svn_pool_create
> >     return apply(_core.svn_pool_create, args)
> >   File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 3081, in _wrap
> >     obj.set_parent_pool(self)
> >   File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 2994, in set_parent_pool
> >     self._parent_pool = parent_pool or application_pool
> >   File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 2982, in <lambda>
> >     __setattr__ = lambda self, name, value: _swig_setattr(self, apr_pool_t, name, value)
> >   File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 22, in _swig_setattr
> >     return _swig_setattr_nondynamic(self,class_type,name,value,0)
> >   File "/usr/lib64/python2.4/site-packages/libsvn/core.py", line 17, in _swig_setattr_nondynamic
> >     self.__dict__[name] = value
> > RuntimeError: instance.__dict__ not accessible in restricted mode
> > 
> > It's an intermittent error, sometimes I get it, sometimes I don't.
> 
> That's the errors one loves. Looks like it's a known issue for more
> than a year:
> 
> http://trac.edgewall.org/ticket/3371

Ugh. But we didn't have the problem before. Any idea what changed, that
could explain why we suddenly have the problem? Maybe the switch to
mod_python? I think we have to switch back to the previous state until
the Trac folks provide a fix.

Thanks,
-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Checking out and comitting to the libsensors-3.x

[Axel Thimm]

[-- Attachment #1.1: Type: text/plain, Size: 1126 bytes --]

Hi,

On Tue, Apr 10, 2007 at 04:23:10PM +0200, Jean Delvare wrote:
> On Thu, 5 Apr 2007 22:31:59 +0200, Axel Thimm wrote:
> > On Thu, Apr 05, 2007 at 10:15:04PM +0200, Jean Delvare wrote:
> > > http://www.lm-sensors.org/wiki/Devices
> > > 
> > > Oops…
> > > Trac detected an internal error:
> > > 

> > > RuntimeError: instance.__dict__ not accessible in restricted mode
> > > 
> > > It's an intermittent error, sometimes I get it, sometimes I don't.
> > 
> > That's the errors one loves. Looks like it's a known issue for more
> > than a year:
> > 
> > http://trac.edgewall.org/ticket/3371
> 
> Ugh. But we didn't have the problem before. Any idea what changed, that
> could explain why we suddenly have the problem? Maybe the switch to
> mod_python? I think we have to switch back to the previous state until
> the Trac folks provide a fix.

I tried one of the fixes mentioned ("PythonInterpreter
main_interpreter"), I can't provoke the bug anymore (tried reload on
the Devices page which previously was giving the error for me). Is
that true on your side, too?
-- 
Axel.Thimm at ATrpms.net

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Checking out and comitting to the libsensors-3.x

[Jean Delvare]

On Tue, 10 Apr 2007 16:43:54 +0200, Axel Thimm wrote:
> On Tue, Apr 10, 2007 at 04:23:10PM +0200, Jean Delvare wrote:
> > Ugh. But we didn't have the problem before. Any idea what changed, that
> > could explain why we suddenly have the problem? Maybe the switch to
> > mod_python? I think we have to switch back to the previous state until
> > the Trac folks provide a fix.
> 
> I tried one of the fixes mentioned ("PythonInterpreter
> main_interpreter"), I can't provoke the bug anymore (tried reload on
> the Devices page which previously was giving the error for me). Is
> that true on your side, too?

It looks OK so far, yes, thanks.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Checking out and comitting to the libsensors-3.x

[Jean Delvare]

Hi all,

On Sun, 8 Apr 2007 10:14:30 +0200, Jean Delvare wrote:
> On Tue, 3 Apr 2007 09:15:28 -0400, Mark M. Hoffman wrote:
> > IMPORTANT NOTE: next time we want to merge trunk changes out to the 3.0.0
> > branch, the merge command will be slightly different.  We must not use r4303
> > as the starting point, but rather r4355; otherwise we might duplicate some
> > changes.  So it is important to remember that we're synced up to r4355.  The
> > convention is to record that information in the commit log when the merge is
> > committed (which I did.)
> > 
> > If there are changes to trunk that don't make sense in the branch, then we can
> > handle that by "anti" cherry-picking them.  E.g. if r4360 is such a change,
> > we'll sync r4355:r4359 and then again r4361:whatever.
> 
> Another method would be to commit to both branches in parallel when a
> given change belongs to both branches. Looking at the changes you just
> merged, it seems that only a small amount of these were really needed
> in 3.0.0. All the changes to the kernel drivers, their documentation,
> lib/chips.*, prog/sensors/chips.* and sensors.conf.eg are for 2.10.x
> only. This doesn't leave that many areas where changes really need to
> be merged.
> 
> Also, parallel commit would have the benefit that we have a better
> history, and no merge delay. Opinion anyone?

As nobody objected, I am going that route from now on (and will catch
up with the few commits that already went in since the last merge.)
Whenever a change applies to both branches, we commit to both in
parallel, and we no longer merge. I only see benefits in doing things
this way. I expect both branches to diverge quickly anyway, except for
sensors-detect.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Checking out and comitting to the libsensors-3.x

[Axel Thimm]

[-- Attachment #1.1: Type: text/plain, Size: 1145 bytes --]

Hi,

On Sun, Apr 08, 2007 at 07:40:30PM +0200, Jean Delvare wrote:
> > But you do get a marker for copies or merges that you can follow to
> > fork off A's history into B's.
> 
> True, but that's hardly convenient if merges are frequent and/or if the
> number of branches is important. I start understanding why people
> working with many branches don't even consider Subversion.

Well, git was written with merges as the first priority, as the kernel
is being cloned and developed as several places
simultaneously. mercurial has also better merge support.

I just stumbled over the following (which is why I'm replying to this
old mail):

http://subversion.tigris.org/merge-tracking/
http://www.orcaware.com/svn/wiki/Svnmerge.py

E.g. svn will one day have the support you need, but you need it
today. :(

(and I wouldn't recommend using the semi-official svnmerge.py, because
the official implemenation may look different and we'd be stuck with
broken upgrade paths - better to switch to git/mercurial if the need
becomes larger - mercurial works under trac, too, and git is about to)
-- 
Axel.Thimm at ATrpms.net

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Checking out and comitting to the libsensors-3.x

[Jean Delvare]

On Sun, 22 Apr 2007 21:03:02 +0200, Axel Thimm wrote:
> Hi,
> 
> On Sun, Apr 08, 2007 at 07:40:30PM +0200, Jean Delvare wrote:
> > > But you do get a marker for copies or merges that you can follow to
> > > fork off A's history into B's.
> > 
> > True, but that's hardly convenient if merges are frequent and/or if the
> > number of branches is important. I start understanding why people
> > working with many branches don't even consider Subversion.
> 
> Well, git was written with merges as the first priority, as the kernel
> is being cloned and developed as several places
> simultaneously. mercurial has also better merge support.
> 
> I just stumbled over the following (which is why I'm replying to this
> old mail):
> 
> http://subversion.tigris.org/merge-tracking/
> http://www.orcaware.com/svn/wiki/Svnmerge.py
> 
> E.g. svn will one day have the support you need, but you need it
> today. :(

I don't think we can see we _need_ it. If it was there, we'd use it.
It's not, we'll do without it, no big deal. We'll simply go with the
parallel commit proposal I made a few days ago, and that will be fine.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors