All of lore.kernel.org
 help / color / mirror / Atom feed
From: Axel Thimm <Axel.Thimm@ATrpms.net>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] Checking out and comitting to the libsensors-3.x
Date: Mon, 02 Apr 2007 12:01:41 +0000	[thread overview]
Message-ID: <20070402120141.GA4847@neu.nirvana> (raw)
In-Reply-To: <4610BC25.8050507@hhs.nl>


[-- 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

  parent reply	other threads:[~2007-04-02 12:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-02  8:17 [lm-sensors] Checking out and comitting to the libsensors-3.x branch Hans de Goede
2007-04-02 11:36 ` [lm-sensors] Checking out and comitting to the libsensors-3.x Jean Delvare
2007-04-02 12:01 ` Axel Thimm [this message]
2007-04-03 13:15 ` Mark M. Hoffman
2007-04-04 19:29 ` Jean Delvare
2007-04-04 19:43 ` Axel Thimm
2007-04-05 20:15 ` Jean Delvare
2007-04-05 20:31 ` Axel Thimm
2007-04-08  8:14 ` Jean Delvare
2007-04-08  8:33 ` Axel Thimm
2007-04-08 17:40 ` Jean Delvare
2007-04-10 14:23 ` Jean Delvare
2007-04-10 14:43 ` Axel Thimm
2007-04-12  9:12 ` Jean Delvare
2007-04-20 13:17 ` Jean Delvare
2007-04-22 19:03 ` Axel Thimm
2007-04-23 11:53 ` Jean Delvare

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070402120141.GA4847@neu.nirvana \
    --to=axel.thimm@atrpms.net \
    --cc=lm-sensors@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.