Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

Garrett Cooper
On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremy <[hidden email]> wrote:
> On 2011-Jan-21 20:01:32 +0100, "Simon L. B. Nielsen" <[hidden email]> wrote:
>>Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful?
>
> Can cvsup-master still lose atomicity of commits?  I suspect it can,
> in which case syncing directly off the SVN master would seem a better
> approach.

I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I
wonder if it's time to look at another solution to this problem as
these annoying stability issues don't appear to be going away. What
about git?

Just some things I'm able to rattle off that come to mind with git..

Some arguments `for git'...

1. One tool to rule them all:
   - cvsup/csup can be replaced with git archive [1].
   - cvs git scales a bit better.
   - less support cost for p4 and lower likelihood of downtime in the
event of critical failure (perforce's proprietary DB is a pain to
recover I've recently discovered from other dealings).
   - svn <-> cvs exporter is no longer required as it's all one SCM.
   - As a side-effect, the bits present in CVS and SVN would now be
100% in sync, unlike cvs which can lead svn in terms of commits (at
least that was the case when I last talked to someone about version
numbering in pkg_install done by re@).
2. More evolved tool:
   - branches are cheap and can be local or remote.
   - distributed SCM seem to work well with large groups of developers.
   - works better with branching and merging from what I've seen.

Some arguments against git...
- The one caveat to cvsup/csup that's awesome is its componentization
capability, i.e. being able to selectively download components in src
/ ports; I'm not 100% sure but there doesn't appear to be a clear
analog in git. It might be achievable through gits remote.<group> in
git-config, git-remote, etc, but I would need to prototype whether or
not this is true.
- Higher learning curve.
- Some slightly annoying nits with stashing local changes when working
on separate branches (need to talk to git maintainers).
- <More items might be here>

    Some more git experienced folks could comment here, but it would
be nice to unify all of the systems under `one flag' for the sake of
simplicity and hopefully the sanity of the tool maintainers (Simon, et
all).
Thanks!
-Garrett
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

Alexander Best-4
On Mon Jan 24 11, Garrett Cooper wrote:

> On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremy <[hidden email]> wrote:
> > On 2011-Jan-21 20:01:32 +0100, "Simon L. B. Nielsen" <[hidden email]> wrote:
> >>Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful?
> >
> > Can cvsup-master still lose atomicity of commits?  I suspect it can,
> > in which case syncing directly off the SVN master would seem a better
> > approach.
>
> I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I
> wonder if it's time to look at another solution to this problem as
> these annoying stability issues don't appear to be going away. What
> about git?
>
> Just some things I'm able to rattle off that come to mind with git..

it would also be nice to have github running on freebsd.org. that way it would
be much easier to discuss src changes without having to point people at a file,
a function or even a specific line. also it would finally kill the
mailinglists, which have lots of issues: spam, broken mailman installation,
people going berserker when they see lines > 80 etc. there have been a few
attempts to introduce a code review system, but since that was all hosted on
foreign websites the idea never cought on and afaik those websites weren't
being supported/promoted by freebsd.org.

but personally i don't expect a change like this to happen in the near future.
basically most of the freebsd administrative people are quite conservative. i
wouldn't be surprised if some them are still trying to run freebsd on their
typewriters. ;)

cheers.
alex

>
> Some arguments `for git'...
>
> 1. One tool to rule them all:
>    - cvsup/csup can be replaced with git archive [1].
>    - cvs git scales a bit better.
>    - less support cost for p4 and lower likelihood of downtime in the
> event of critical failure (perforce's proprietary DB is a pain to
> recover I've recently discovered from other dealings).
>    - svn <-> cvs exporter is no longer required as it's all one SCM.
>    - As a side-effect, the bits present in CVS and SVN would now be
> 100% in sync, unlike cvs which can lead svn in terms of commits (at
> least that was the case when I last talked to someone about version
> numbering in pkg_install done by re@).
> 2. More evolved tool:
>    - branches are cheap and can be local or remote.
>    - distributed SCM seem to work well with large groups of developers.
>    - works better with branching and merging from what I've seen.
>
> Some arguments against git...
> - The one caveat to cvsup/csup that's awesome is its componentization
> capability, i.e. being able to selectively download components in src
> / ports; I'm not 100% sure but there doesn't appear to be a clear
> analog in git. It might be achievable through gits remote.<group> in
> git-config, git-remote, etc, but I would need to prototype whether or
> not this is true.
> - Higher learning curve.
> - Some slightly annoying nits with stashing local changes when working
> on separate branches (need to talk to git maintainers).
> - <More items might be here>
>
>     Some more git experienced folks could comment here, but it would
> be nice to unify all of the systems under `one flag' for the sake of
> simplicity and hopefully the sanity of the tool maintainers (Simon, et
> all).
> Thanks!
> -Garrett

--
a13x
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

Ivan Voras
In reply to this post by Garrett Cooper
On 24.1.2011 9:13, Garrett Cooper wrote:
> On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremy<[hidden email]>  wrote:
>> On 2011-Jan-21 20:01:32 +0100, "Simon L. B. Nielsen"<[hidden email]>  wrote:
>>> Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful?
>>
>> Can cvsup-master still lose atomicity of commits?  I suspect it can,
>> in which case syncing directly off the SVN master would seem a better
>> approach.

I think des is working on "svnup" to work directly on the SVN tree.

> I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I
> wonder if it's time to look at another solution to this problem as
> these annoying stability issues don't appear to be going away. What
> about git?

As long as we're choosing bikeshed colour, I would like to drop
"mercurial" here :)

Mainly because of this:

 > - Higher learning curve.

I found Mercurial to have an easier learning curve and to be something
like a "DSCM for the users of CVS/SVN".

 > - Some slightly annoying nits with stashing local changes when working
 > on separate branches (need to talk to git maintainers).

I don't know if we're talking about the same thing, but I've also
noticed git tends to do things the long way around which should be
simple. Git's also much "lower level".

They both support pretty much the same feature set; here's a cute but
dated comparison:

http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/

Hg is/was AFAIK used by Sun.

Anyway, personally, svn is good enough :)


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

Garrett Cooper-4
On Mon, Jan 24, 2011 at 5:33 AM, Ivan Voras <[hidden email]> wrote:

> On 24.1.2011 9:13, Garrett Cooper wrote:
>>
>> On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremy<[hidden email]>  wrote:
>>>
>>> On 2011-Jan-21 20:01:32 +0100, "Simon L. B. Nielsen"<[hidden email]>
>>>  wrote:
>>>>
>>>> Perhaps we should just set the tinderbox up to sync directly of
>>>> cvsup-master instead if that makes it more useful?
>>>
>>> Can cvsup-master still lose atomicity of commits?  I suspect it can,
>>> in which case syncing directly off the SVN master would seem a better
>>> approach.
>
> I think des is working on "svnup" to work directly on the SVN tree.
>
>> I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I
>> wonder if it's time to look at another solution to this problem as
>> these annoying stability issues don't appear to be going away. What
>> about git?
>
> As long as we're choosing bikeshed colour, I would like to drop "mercurial"
> here :)
>
> Mainly because of this:
>
>> - Higher learning curve.
>
> I found Mercurial to have an easier learning curve and to be something like
> a "DSCM for the users of CVS/SVN".
>
>> - Some slightly annoying nits with stashing local changes when working
>> on separate branches (need to talk to git maintainers).
>
> I don't know if we're talking about the same thing, but I've also noticed
> git tends to do things the long way around which should be simple. Git's
> also much "lower level".
>
> They both support pretty much the same feature set; here's a cute but dated
> comparison:
>
> http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/
>
> Hg is/was AFAIK used by Sun.
>
> Anyway, personally, svn is good enough :)

    Ok. Obviously this was just a fleeting thought so let's close the
git topic. I do hope that whatever des has cooking up though can
replace cvsup/csup reliably though, and if CVS would die at least that
would be nice...
Thanks,
-Garrett
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

Diane Bruce
In reply to this post by Ivan Voras
On Mon, Jan 24, 2011 at 02:33:25PM +0100, Ivan Voras wrote:
> On 24.1.2011 9:13, Garrett Cooper wrote:
> >On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremy<[hidden email]>  wrote:
> >>On 2011-Jan-21 20:01:32 +0100, "Simon L. B. Nielsen"<[hidden email]>  
> >>wrote:
> >>>Perhaps we should just set the tinderbox up to sync directly of
...
>
> As long as we're choosing bikeshed colour, I would like to drop
> "mercurial" here :)

As long as it is not GPL.

- Diane
--
- [hidden email] [hidden email] http://www.db.net/~db
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

Ivan Voras
On 24 January 2011 19:31, Diane Bruce <[hidden email]> wrote:

> As long as it is not GPL.

Unless there's a missing smiley in that sentence there, it is a tough
requirement. Of the major SCMs, only Subversion is non-GPL-ed (even
CVS is...).
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

Diane Bruce
On Mon, Jan 24, 2011 at 08:02:37PM +0100, Ivan Voras wrote:
> On 24 January 2011 19:31, Diane Bruce <[hidden email]> wrote:
>
> > As long as it is not GPL.
>
> Unless there's a missing smiley in that sentence there, it is a tough

IRL I'm known to be very dry humoured, I am deadly in e-mail or IRC.

> requirement. Of the major SCMs, only Subversion is non-GPL-ed (even

QED

> CVS is...).

CVS is/was dual licenced. There is also the work openbsd started with CVS
sometime ago.

Given the work that is being done on clang/llvm to get a non GPL compiler
into the tree, perhaps efforts would be better spent on finding SCMs
that were also non GPL. There certainly would not be a chance of putting
mercurial or git into base for example.

Perhaps a point to consider.

- Diane
--
- [hidden email] [hidden email] http://www.db.net/~db
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

Garrett Cooper-4
On Mon, Jan 24, 2011 at 11:48 AM, Diane Bruce <[hidden email]> wrote:

> On Mon, Jan 24, 2011 at 08:02:37PM +0100, Ivan Voras wrote:
>> On 24 January 2011 19:31, Diane Bruce <[hidden email]> wrote:
>>
>> > As long as it is not GPL.
>>
>> Unless there's a missing smiley in that sentence there, it is a tough
>
> IRL I'm known to be very dry humoured, I am deadly in e-mail or IRC.
>
>> requirement. Of the major SCMs, only Subversion is non-GPL-ed (even
>
> QED
>
>> CVS is...).
>
> CVS is/was dual licenced. There is also the work openbsd started with CVS
> sometime ago.
>
> Given the work that is being done on clang/llvm to get a non GPL compiler
> into the tree, perhaps efforts would be better spent on finding SCMs
> that were also non GPL. There certainly would not be a chance of putting
> mercurial or git into base for example.

    But we don't compile CVS, SVN, etc into our sources. I thought
that was the whole point of doing the gcc -> clang (and friends)
conversion, not that the GPL is an undesirable license. Maybe I was
missing something about the whole textproc stuff being replaced though
(groff, etc) with NetBSD equivalents *shrugs*.
    Given that this is getting more philosophical than technical,
maybe we should move the discussion elsewhere (i.e. not hackers@)?

> Perhaps a point to consider.

Thanks!
-Garrett
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

Diane Bruce
On Mon, Jan 24, 2011 at 12:12:19PM -0800, Garrett Cooper wrote:
> On Mon, Jan 24, 2011 at 11:48 AM, Diane Bruce <[hidden email]> wrote:
> > On Mon, Jan 24, 2011 at 08:02:37PM +0100, Ivan Voras wrote:
> >> On 24 January 2011 19:31, Diane Bruce <[hidden email]> wrote:
> >>
...
>     But we don't compile CVS, SVN, etc into our sources. I thought

which rcs.
If you check, the file format on the SVN server is rcs compatible, in
fact local checkins using svn will work just fine.

>     Given that this is getting more philosophical than technical,
> maybe we should move the discussion elsewhere (i.e. not hackers@)?

I'd suggest we support fossil (devel/fossil)
http://fossil-scm.org

No. But in future, keep in mind us old timers are not _that_ conservative.

> > Perhaps a point to consider.
>
> Thanks!

You are welcome.

> -Garrett


- Diane
--
- [hidden email] [hidden email] http://www.db.net/~db
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

Julian H. Stacey-3
In reply to this post by Ivan Voras
> They both support pretty much the same feature set; here's a cute but
> dated comparison:
>
> http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/

http://wiki.freebsd.org/VersionControl
        Table of features comparing SVN HG GIT MTN

http://wiki.freebsd.org/
        section Development resources (near base of page)
                Clickable to docs on Mercurial & HG & Git etc.

Anyone having info not documented there already, could help by
contributing there ?
Maybe add another tool column or add another attribute row, whatever ?

Disclaimer:
        I'm not an author, just a reader, no opinion on one over
        the other, but that table seems a central place to work
        toward informed choice ?

Cheers,
Julian
--
Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
 Mail plain text;  Not quoted-printable, Not HTML, Not base 64.
 Reply below text sections not at top, to avoid breaking cumulative context.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

Warner Losh
In reply to this post by Garrett Cooper
Regardless of the benefits, unless there's someone to setup the
infrastructure to run things, we're not going to change.

We should at least have a master seed for git that people can pull from
before we talk about doing anything further.  git has the ability to
pull from svn, so this should be relatively easy to get going.

Warner

On 01/24/2011 01:13, Garrett Cooper wrote:

> On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremy<[hidden email]>  wrote:
>> On 2011-Jan-21 20:01:32 +0100, "Simon L. B. Nielsen"<[hidden email]>  wrote:
>>> Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful?
>> Can cvsup-master still lose atomicity of commits?  I suspect it can,
>> in which case syncing directly off the SVN master would seem a better
>> approach.
> I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I
> wonder if it's time to look at another solution to this problem as
> these annoying stability issues don't appear to be going away. What
> about git?
>
> Just some things I'm able to rattle off that come to mind with git..
>
> Some arguments `for git'...
>
> 1. One tool to rule them all:
>     - cvsup/csup can be replaced with git archive [1].
>     - cvs git scales a bit better.
>     - less support cost for p4 and lower likelihood of downtime in the
> event of critical failure (perforce's proprietary DB is a pain to
> recover I've recently discovered from other dealings).
>     - svn<->  cvs exporter is no longer required as it's all one SCM.
>     - As a side-effect, the bits present in CVS and SVN would now be
> 100% in sync, unlike cvs which can lead svn in terms of commits (at
> least that was the case when I last talked to someone about version
> numbering in pkg_install done by re@).
> 2. More evolved tool:
>     - branches are cheap and can be local or remote.
>     - distributed SCM seem to work well with large groups of developers.
>     - works better with branching and merging from what I've seen.
>
> Some arguments against git...
> - The one caveat to cvsup/csup that's awesome is its componentization
> capability, i.e. being able to selectively download components in src
> / ports; I'm not 100% sure but there doesn't appear to be a clear
> analog in git. It might be achievable through gits remote.<group>  in
> git-config, git-remote, etc, but I would need to prototype whether or
> not this is true.
> - Higher learning curve.
> - Some slightly annoying nits with stashing local changes when working
> on separate branches (need to talk to git maintainers).
> -<More items might be here>
>
>      Some more git experienced folks could comment here, but it would
> be nice to unify all of the systems under `one flag' for the sake of
> simplicity and hopefully the sanity of the tool maintainers (Simon, et
> all).
> Thanks!
> -Garrett
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
>
>
>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

Perry Hutchison
In reply to this post by Diane Bruce
Diane Bruce <[hidden email]> wrote:

> There certainly would not be a chance of putting
> mercurial or git into base for example.

Completely apart from licensing, another strike against
mercurial is that it is written in Python, so it couldn't
go into base unless Python also went into base.

BTW this topic came up on ports@ about 3 months ago:

http://lists.freebsd.org/pipermail/freebsd-ports/2010-September/063675.html
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

Ivan Voras
On 25 January 2011 11:22,  <[hidden email]> wrote:
> Diane Bruce <[hidden email]> wrote:
>
>> There certainly would not be a chance of putting
>> mercurial or git into base for example.
>
> Completely apart from licensing, another strike against
> mercurial is that it is written in Python, so it couldn't
> go into base unless Python also went into base.

Of course. OTOH, this topic will only become relevant if anyone
notices that Subversion gets committed into base ;)
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

Giorgos Keramidas
In reply to this post by Perry Hutchison
On Tue, 25 Jan 2011 02:22:34 -0800, [hidden email] wrote:
>Diane Bruce <[hidden email]> wrote:
>> There certainly would not be a chance of putting mercurial or git
>> into base for example.
>
> Completely apart from licensing, another strike against mercurial is
> that it is written in Python, so it couldn't go into base unless
> Python also went into base.

This argument is actually a bit weak for most of the VCS'es out there
(including svn by the way).

We don't really *need* to import the full VCS itself into FreeBSD.  For
instance, Subversion is also not part of the base system.  It works fine
as a port that people can install.

There's really _nothing_ wrong with a VCS that is a port/package.  We
used to have CVS into the base system as "the official VCS", but this is
no longer the case for the subversion repo of src/.  IMO this hasn't
really caused any major problem with the people who want to check out
and patch the source tree.

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

Alexander Best-4
On Tue Jan 25 11, Giorgos Keramidas wrote:

> On Tue, 25 Jan 2011 02:22:34 -0800, [hidden email] wrote:
> >Diane Bruce <[hidden email]> wrote:
> >> There certainly would not be a chance of putting mercurial or git
> >> into base for example.
> >
> > Completely apart from licensing, another strike against mercurial is
> > that it is written in Python, so it couldn't go into base unless
> > Python also went into base.
>
> This argument is actually a bit weak for most of the VCS'es out there
> (including svn by the way).
>
> We don't really *need* to import the full VCS itself into FreeBSD.  For
> instance, Subversion is also not part of the base system.  It works fine
> as a port that people can install.
>
> There's really _nothing_ wrong with a VCS that is a port/package.  We
> used to have CVS into the base system as "the official VCS", but this is
> no longer the case for the subversion repo of src/.  IMO this hasn't
> really caused any major problem with the people who want to check out
> and patch the source tree.

imo having a VCS in base is a bad idea. it makes it much harder to keep it in
sync with the vendor version. to update a port involves very little
administrative work. on the other hand updating vendor software in base
involves quite a lot of importing etc.

also please don't forget that having a VCS in base means there's only *one*
version of the VCS available. having it in the ports tree makes it possible to
have a legacy release, a stable release, an experimental release and also a
development snapshot. of course there could be a stable release in base and if
users want to they can install a more recent version from ports, but that
doesn't really make sense imo.

also a VCS is not really an essential part of an OS. with clang/llvm e.g. a
version must exist in base, since it's not possible to invoke /usr/local in
order to build the system. the VCS however is not part of the build toolchain
however (except 'make update' maybe).

so -1 for moving a new VCS to base.

also i think freebsd should stick to a major VCS, like git and not some lesser
known obscure VCS. with git you have all the linux people behind it, which
means it will be updated regularly, bugs will be fixed quite fast etc. there's
no point in switching to some rather unknown VCS where the developers decide
after 2 years that they don't have any more spare time and have to abandon the
project.

to be quite honest: the freebsd community doesn't have the manpower to maintain
a VCS by itself. you *need* other developers in order to keep it up to date.
just look at GNATS e.g. gnu abandoned it quite a while ago and the bugbusting
community is just to small to either update to a more recent version of GNATS
or switch to something like bugzilla.

again: you *need* support from other developers in order to maintain a VCS
properly. so git is the best choice imo.

just my 0.02$

cheers.
alex

>

--
a13x
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

Diane Bruce
In reply to this post by Giorgos Keramidas
On Tue, Jan 25, 2011 at 01:40:50PM +0100, Giorgos Keramidas wrote:

> On Tue, 25 Jan 2011 02:22:34 -0800, [hidden email] wrote:
> >Diane Bruce <[hidden email]> wrote:
> >> There certainly would not be a chance of putting mercurial or git
> >> into base for example.
> >
> > Completely apart from licensing, another strike against mercurial is
> > that it is written in Python, so it couldn't go into base unless
> > Python also went into base.
>
> This argument is actually a bit weak for most of the VCS'es out there
> (including svn by the way).

Notice I never ever suggested we might want to do such a thing.
All I said was there would be not a chance of GPL code being added.
The additional argument of mercurial not being added because of its
dependancy on python is immaterial.

>
> We don't really *need* to import the full VCS itself into FreeBSD.  For
> instance, Subversion is also not part of the base system.  It works fine
> as a port that people can install.

I agree.  Indeed, I would argue that there is other code in base that
should come out.  But I don't want to get that flamefest going again. ;-)

The argument is not putting a VCS into base, the argument is what VCS
to look at in future.  'fossil' is certainly a viable candidate.
I am agreeing the arguments on which VCS to use should be based on the
merits of the VCS itself, not on its licence.

However, if in the long term we chose 'fossil' and then decided that 'fossil'
was absolutely necessary for base, then it would have far less resistance
than a GPL VCS.  That's a small plus, I never said it was a strong plus.


- Diane
--
- [hidden email] [hidden email] http://www.db.net/~db
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

Diane Bruce
In reply to this post by Alexander Best-4
On Tue, Jan 25, 2011 at 02:05:17PM +0000, Alexander Best wrote:
> On Tue Jan 25 11, Giorgos Keramidas wrote:
> > On Tue, 25 Jan 2011 02:22:34 -0800, [hidden email] wrote:
> > >Diane Bruce <[hidden email]> wrote:
> > >> There certainly would not be a chance of putting mercurial or git
> > >> into base for example.
...
> > no longer the case for the subversion repo of src/.  IMO this hasn't
> > really caused any major problem with the people who want to check out
> > and patch the source tree.

Note I never said it should be importable into base.

> also i think freebsd should stick to a major VCS, like git and not some lesser

Argumentum ad populum.

If the VCS is 1) easy to use 2) easy to maintain and has a body of people
working on it already 3) can import other VCS formats, then why not?
Also note that using an appeal to popularity suggests
we should go with the flow and stop working on llvm/clang.  Afer all,
everyone else uses gcc.

As it happens, fossil is quite tiny, fairly feature rich, BSDL'd and in
active development.  QED

All that being said,  I am not interested in bikeshedding right now.
Those who will look at the alternatives intelligently should do so.

> cheers.
> alex

- Diane
--
- [hidden email] [hidden email] http://www.db.net/~db
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

Gleb Kurtsou-3
In reply to this post by Alexander Best-4
On (24/01/2011 11:33), Alexander Best wrote:

> On Mon Jan 24 11, Garrett Cooper wrote:
> > On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremy <[hidden email]> wrote:
> > > On 2011-Jan-21 20:01:32 +0100, "Simon L. B. Nielsen" <[hidden email]> wrote:
> > >>Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful?
> > >
> > > Can cvsup-master still lose atomicity of commits?  I suspect it can,
> > > in which case syncing directly off the SVN master would seem a better
> > > approach.
> >
> > I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I
> > wonder if it's time to look at another solution to this problem as
> > these annoying stability issues don't appear to be going away. What
> > about git?
> >
> > Just some things I'm able to rattle off that come to mind with git..
>
> it would also be nice to have github running on freebsd.org. that way it would
> be much easier to discuss src changes without having to point people at a file,
> a function or even a specific line. also it would finally kill the
> mailinglists, which have lots of issues: spam, broken mailman installation,
> people going berserker when they see lines > 80 etc. there have been a few
> attempts to introduce a code review system, but since that was all hosted on
> foreign websites the idea never cought on and afaik those websites weren't
> being supported/promoted by freebsd.org.

Having github would be nice, but it's not open source. Another option
could be gitorious, there are merge requests with review option[1], patch
review, already hosted freebsd repository[2].

All we need as a first step is developers starting accepting merge
requests from each other, people use it already[3].

1. http://blog.gitorious.org/2009/11/06/awesome-code-review/
2. http://gitorious.org/freebsd
3. http://gitorious.org/freebsd/repositories

> but personally i don't expect a change like this to happen in the near future.
> basically most of the freebsd administrative people are quite conservative. i
> wouldn't be surprised if some them are still trying to run freebsd on their
> typewriters. ;)
>
> cheers.
> alex
>
> >
> > Some arguments `for git'...
> >
> > 1. One tool to rule them all:
> >    - cvsup/csup can be replaced with git archive [1].
> >    - cvs git scales a bit better.
> >    - less support cost for p4 and lower likelihood of downtime in the
> > event of critical failure (perforce's proprietary DB is a pain to
> > recover I've recently discovered from other dealings).
> >    - svn <-> cvs exporter is no longer required as it's all one SCM.
> >    - As a side-effect, the bits present in CVS and SVN would now be
> > 100% in sync, unlike cvs which can lead svn in terms of commits (at
> > least that was the case when I last talked to someone about version
> > numbering in pkg_install done by re@).
> > 2. More evolved tool:
> >    - branches are cheap and can be local or remote.
> >    - distributed SCM seem to work well with large groups of developers.
> >    - works better with branching and merging from what I've seen.
> >
> > Some arguments against git...
> > - The one caveat to cvsup/csup that's awesome is its componentization
> > capability, i.e. being able to selectively download components in src
> > / ports; I'm not 100% sure but there doesn't appear to be a clear
> > analog in git. It might be achievable through gits remote.<group> in
> > git-config, git-remote, etc, but I would need to prototype whether or
> > not this is true.
> > - Higher learning curve.
> > - Some slightly annoying nits with stashing local changes when working
> > on separate branches (need to talk to git maintainers).
> > - <More items might be here>
> >
> >     Some more git experienced folks could comment here, but it would
> > be nice to unify all of the systems under `one flag' for the sake of
> > simplicity and hopefully the sanity of the tool maintainers (Simon, et
> > all).
> > Thanks!
> > -Garrett
>
> --
> a13x
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

Garrett Cooper
On Tue, Jan 25, 2011 at 11:09 PM, Gleb Kurtsou <[hidden email]> wrote:

> On (24/01/2011 11:33), Alexander Best wrote:
>> On Mon Jan 24 11, Garrett Cooper wrote:
>> > On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremy <[hidden email]> wrote:
>> > > On 2011-Jan-21 20:01:32 +0100, "Simon L. B. Nielsen" <[hidden email]> wrote:
>> > >>Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful?
>> > >
>> > > Can cvsup-master still lose atomicity of commits?  I suspect it can,
>> > > in which case syncing directly off the SVN master would seem a better
>> > > approach.
>> >
>> > I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I
>> > wonder if it's time to look at another solution to this problem as
>> > these annoying stability issues don't appear to be going away. What
>> > about git?
>> >
>> > Just some things I'm able to rattle off that come to mind with git..
>>
>> it would also be nice to have github running on freebsd.org. that way it would
>> be much easier to discuss src changes without having to point people at a file,
>> a function or even a specific line. also it would finally kill the
>> mailinglists, which have lots of issues: spam, broken mailman installation,
>> people going berserker when they see lines > 80 etc. there have been a few
>> attempts to introduce a code review system, but since that was all hosted on
>> foreign websites the idea never cought on and afaik those websites weren't
>> being supported/promoted by freebsd.org.
>
> Having github would be nice, but it's not open source. Another option
> could be gitorious, there are merge requests with review option[1], patch
> review, already hosted freebsd repository[2].
>
> All we need as a first step is developers starting accepting merge
> requests from each other, people use it already[3].
>
> 1. http://blog.gitorious.org/2009/11/06/awesome-code-review/
> 2. http://gitorious.org/freebsd
> 3. http://gitorious.org/freebsd/repositories

This is only for src though. I was going to start up some mirroring of
ports as well on gitorious, but it would have been nice if it could
have been covered like so:

freebsd/docs.git
freebsd/ports.git
freebsd/src.git

So that way people could just clone one of the above and work merrily
in the component as they felt fit, or check out all three and work
away as necessary. Plus it would be more 1:1 than it currently is.

Thanks!
-Garrett
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

Julian H. Stacey-3
In reply to this post by Alexander Best-4
Hi,
Alex
> order to build the system. the VCS however is not part of the build toolchain
> however (except 'make update' maybe).

Some good points,  but also remember make release also uses cvs
         grep CVS /usr/src/release/Makefile

Cheers,
Julian
--
Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
 Mail plain text;  Not quoted-printable, Not HTML, Not base 64.
 Reply below text sections not at top, to avoid breaking cumulative context.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
12