version control policy

version control policy

[Petr Ovtchenkov]

Good day!

I want to understand aspects in version control policy.

- What the principles of branches? I.e. what the relation between,
  say, master, binutils-2_28-branch and gdb-7.12-branch?

  What the relation between binutils-2_28-branch and published
  binutils 2.28, gdb-7.12-branch and published GDB 7.12.1?

- Is bot's commits (like 40d57b1947) really useful?

Thanks,

   - ptr

Re: version control policy

[Tristan Gingold]

> On 08 Mar 2017, at 19:41, Petr Ovtchenkov <ptr@void-ptr.info> wrote:
> 
> Good day!
> 
> I want to understand aspects in version control policy.
> 
> - What the principles of branches? I.e. what the relation between,
>  say, master, binutils-2_28-branch and gdb-7.12-branch?

Branches are created from master.

>  What the relation between binutils-2_28-branch and published
>  binutils 2.28, gdb-7.12-branch and published GDB 7.12.1?

Published releases are created from branches.  Usually, there is also a tag on the commit for the release.

Tristan.

Re: version control policy

[Petr Ovtchenkov]

On Fri, 10 Mar 2017 15:15:05 +0100
Tristan Gingold <gingold@adacore.com> wrote:

> 
> > On 08 Mar 2017, at 19:41, Petr Ovtchenkov <ptr@void-ptr.info> wrote:
> > 
> > Good day!
> > 
> > I want to understand aspects in version control policy.
> > 
> > - What the principles of branches? I.e. what the relation between,
> >  say, master,   and gdb-7.12-branch?
> 
> Branches are created from master.

Do you really see on commits graph?

Because binutils and gdb share repo and build infrastructure,
but has no clean code exchange between gdb/binutils branches,
what gdb will build when I make build from, say, e2e9a61f5b29 ?

Without bot

>> - Is bot's commits (like 40d57b1947) really useful?

the development process would be observed more clearly.

> >  What the relation between binutils-2_28-branch and published
> >  binutils 2.28, gdb-7.12-branch and published GDB 7.12.1?
> 
> Published releases are created from branches.  Usually, there is also a tag on the commit for the
> release.

Well, gdb team set labels. Looks, that binutils team prefer branches instead.
And both teams push to master on daily development basis, right?

--

   - ptr

Re: version control policy

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

On 10 Mar 2017 19:49, Petr Ovtchenkov wrote:
> On Fri, 10 Mar 2017 15:15:05 +0100 Tristan Gingold wrote:
> > > On 08 Mar 2017, at 19:41, Petr Ovtchenkov wrote:
> > > - What the principles of branches? I.e. what the relation between,
> > >  say, master,   and gdb-7.12-branch?
> > 
> > Branches are created from master.
> 
> Do you really see on commits graph?

sorry, but what does this mean ?

> Because binutils and gdb share repo and build infrastructure,
> but has no clean code exchange between gdb/binutils branches,
> what gdb will build when I make build from, say, e2e9a61f5b29 ?

both projects share the master branch, and it's up to each project
to choose when to branch based on their own release schedule.

giving a random commit doesn't make much sense in the git world.
what branch are you looking at ?

> > >  What the relation between binutils-2_28-branch and published
> > >  binutils 2.28, gdb-7.12-branch and published GDB 7.12.1?
> > 
> > Published releases are created from branches.  Usually, there is also a tag on the commit for the
> > release.
> 
> Well, gdb team set labels. Looks, that binutils team prefer branches instead.

there's no such thing as "labels" in git.  Tristan is correct:
both projects create release branches, and then they tag their
releases from those branches when they're ready.

> And both teams push to master on daily development basis, right?

correct
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: version control policy

[Petr Ovtchenkov]

On Sat, 11 Mar 2017 20:48:08 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> On 10 Mar 2017 19:49, Petr Ovtchenkov wrote:
> > On Fri, 10 Mar 2017 15:15:05 +0100 Tristan Gingold wrote:
> > > > On 08 Mar 2017, at 19:41, Petr Ovtchenkov wrote:
> > > > - What the principles of branches? I.e. what the relation between,
> > > >  say, master,   and gdb-7.12-branch?
> > > 
> > > Branches are created from master.
> > 
> > Do you really see on commits graph?
> 
> sorry, but what does this mean ?
> 
> > Because binutils and gdb share repo and build infrastructure,
> > but has no clean code exchange between gdb/binutils branches,
> > what gdb will build when I make build from, say, e2e9a61f5b29 ?
> 
> both projects share the master branch, and it's up to each project
> to choose when to branch based on their own release schedule.
> 
> giving a random commit doesn't make much sense in the git world.
> what branch are you looking at ?
> 
> > > >  What the relation between binutils-2_28-branch and published
> > > >  binutils 2.28, gdb-7.12-branch and published GDB 7.12.1?
> > > 
> > > Published releases are created from branches.  Usually, there is also a tag on the commit for
> > > the release.
> > 
> > Well, gdb team set labels. Looks, that binutils team prefer branches instead.
> 
> there's no such thing as "labels" in git.  Tristan is correct:
> both projects create release branches, and then they tag their
> releases from those branches when they're ready.
> 
> > And both teams push to master on daily development basis, right?
> 
> correct
> -mike

Hmm, you have sheer talent to give trivial answers and just cut off some
(inconvenient?) questions.

Let's repeat:

   Is bot's commits (like 40d57b1947) really useful?

I see problems from ones, but not understand benefit.
Can you explain advantage of bot's commits that outweigh garbage in the commit tree?


The second question was (release numbers are mentioned below as example only):

  I want to build binutils 2.28 _and_ gdb 7.12.1 from primary git repo.
  What branch(s), tag(s), ... I should use? If commits points of gdb release
  and binutils release are different, what I should say to build 
     - binutils without gdb
       (i.e. --disable-gdb --disable-libdecnumber --disable-readline --disable-sim)
     - gdb without binutils
       (?)

The solution of this problem isn't clear for me, becouse I'm unsure that one installation
will not partially overwrite another.

Thanks,

--

   - ptr

Re: version control policy

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]

On 13 Mar 2017 08:40, Petr Ovtchenkov wrote:
> Hmm, you have sheer talent to give trivial answers and just cut off some
> (inconvenient?) questions.

don't be rude.  so far you haven't contributed anything useful,
yet you're asking other people for help.

i deleted that portion because i had nothing to add.  leaving
it in the quoted context would simply be confusing.

> The second question was (release numbers are mentioned below as example only):

that wasn't in the e-mail i responded to, nor did you ask that question.

>   I want to build binutils 2.28 _and_ gdb 7.12.1 from primary git repo.

you cannot.  as i already said, they are on different schedules.
if you want to build binutils-2.28, get the 2.28 checkout and build
it.  then get a different gdb 7.12.1 checkout and build that.

>   What branch(s), tag(s), ... I should use?

you're asking general git questions here.  if you want to build a specific
release, then you use a tag.  if you want to build something newer than
the release, but part of that release series, then use the branch.

a trivial grep locates all of these things:
	git tag -l | grep gdb.*7.12.1
	git tag -l | grep binutils.*2.28
	git branch -a | grep gdb.*7.12
	git branch -a | grep binutils.*2.28

>   and binutils release are different, what I should say to build 
>      - binutils without gdb
>        (i.e. --disable-gdb --disable-libdecnumber --disable-readline --disable-sim)
>      - gdb without binutils
>        (?)
> 
> The solution of this problem isn't clear for me, becouse I'm unsure that one installation
> will not partially overwrite another.

yes, if you build from git, you need to take care to disable the parts
from the other project.  or use a release tarball instead of messing
with git tags because it'll be stripped down already.

for binutils: --disable-{gdb,libdecnumber,sim}
for gdb: --disable-{binutils,etc,gas,gold,gprof,ld}
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: version control policy

[Petr Ovtchenkov]

Just for summary:
  no common "release" commit for binutils and gdb, so build
  "release" are
    - for binutils: --disable-{gdb,libdecnumber,sim}
    - for gdb: --disable-{binutils,etc,gas,gold,gprof,ld}
   within sources for proper branch/tag (differ for gdb and binutils)

--

  - ptr