|
git copies of cvs modules available
Dear all,
htdocs, othersrc, pkgsrc, src and xsrc are now available as
(bare) git repository copies at
http://ftp.netbsd.org/pub/NetBSD/misc/repositories/git.
These repositories are currently updated every 30 minutes.
They are not authoritative and are not meant to replace cvs,
but if you want to track your development that is not yet fit
for committing into cvs head or sending in as a PR, and want to
use git for that, they may serve as a convenient starting point
or reference.
regards,
spz
|
|
Re: git copies of cvs modules available
On 13.10.2009, at 9:38, S.P.Zeidler wrote:
> Dear all,
>
> htdocs, othersrc, pkgsrc, src and xsrc are now available as
> (bare) git repository copies at
> http://ftp.netbsd.org/pub/NetBSD/misc/repositories/git.
> These repositories are currently updated every 30 minutes.
>
I love you! I spent some frustrating time last week trying to create
local updatable GIT clones using git-cvsimport, and had to give up
deciding the script is not designed for modules this big at all.
--
Filip Hajny
Joyent Inc.
|
|
Re: git copies of cvs modules available
|
|
Re: git copies of cvs modules available
Hi,
Thus wrote Filip Hajny ( filip@...):
> Getting 404s as I try to clone:
[...]
> Sounds like the copy is not 100% healthy.
The files you are looking for are there, you're "just" not getting them
served. I have a suspicion why that happened (same problem as with pkg_add
really, a concurrent connections limit behaving as a connection rate
limit), and may have stopped it happening.
Please retry?
regards,
spz
--
spz@... (S.P.Zeidler)
|
|
Re: git copies of cvs modules available
On 13.10.2009, at 16:34, S.P.Zeidler wrote:
> Hi,
>
> Thus wrote Filip Hajny ( filip@...):
>
>> Getting 404s as I try to clone:
> [...]
>> Sounds like the copy is not 100% healthy.
>
> The files you are looking for are there, you're "just" not getting
> them
> served. I have a suspicion why that happened (same problem as with
> pkg_add
> really, a concurrent connections limit behaving as a connection rate
> limit), and may have stopped it happening.
>
> Please retry?
>
Thanks, worked nicely now.
F
|
|
Re: git copies of cvs modules available
On Tue 13 Oct 2009 at 09:38:27 +0200, S.P.Zeidler wrote:
> Dear all,
>
> htdocs, othersrc, pkgsrc, src and xsrc are now available as
> (bare) git repository copies at
> http://ftp.netbsd.org/pub/NetBSD/misc/repositories/git.
That is great! Thanks!
> These repositories are currently updated every 30 minutes.
>
> They are not authoritative and are not meant to replace cvs,
indeed, since user need to be aware of a caveat: All $NetBSD$ tags
appear to be wrong. They have the value as of the checkin of each
version of each file, not the checkout, so they are always 1 version
behind. (I checked this on src/Makefile which shows this in cvs
# $NetBSD: Makefile,v 1.274 2009/09/04 17:21:33 pooka Exp $
and this in the git version:
# $NetBSD: Makefile,v 1.273 2009/08/30 01:49:42 dyoung Exp $
but the edits regarding "do-sys-rump-dev-lib" are actually in it.)
(There has been a very heated discussion among GIT people why keyword
expansion is supposed to be evil. They are not going to be convinced to
implement it. I am very annoyed by that.)
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- You author it, and I'll reader it.
\X/ rhialto/at/xs4all.nl -- Cetero censeo "authored" delendum esse.
|
|
Re: git copies of cvs modules available
Rhialto < rhialto@...> writes:
> That is great! Thanks!
Indeed, this is awesome! I've experimented with importing pkgsrc
into bzr, but even with all the recent improvements, it's still
no good. Quite a shame, I think. I've just been working with
silly non-history-preserving branches. I use git at work and
really hate it, but not so much as to prevent me from switching
over for pkgsrc work :).
> > They are not authoritative and are not meant to replace cvs,
It's a good start. Maybe people will experiment with it and
learn how we could be working.
> indeed, since user need to be aware of a caveat: All $NetBSD$ tags
> appear to be wrong. They have the value as of the checkin of each
> version of each file, not the checkout, so they are always 1 version
> behind. (I checked this on src/Makefile which shows this in cvs
>
> # $NetBSD: Makefile,v 1.274 2009/09/04 17:21:33 pooka Exp $
>
> and this in the git version:
>
> # $NetBSD: Makefile,v 1.273 2009/08/30 01:49:42 dyoung Exp $
That's how it works in CVS. The keywords are expanded by your
client in the working copy. Then the expanded form is committed
when you commit. Thus, the repository is always one behind.
> (There has been a very heated discussion among GIT people why keyword
> expansion is supposed to be evil. They are not going to be convinced to
> implement it. I am very annoyed by that.)
They are evil. Evil evil evil evil. EVIL! No modern system
supports them, nor are they likely, and we're all the better
for it.
--
Eric Gillespie <*> epg@...
|
|
Re: git copies of cvs modules available
On 10/14/09 04:44, Eric Gillespie wrote:
> Rhialto< rhialto@...> writes:
>
>> That is great! Thanks!
>
> Indeed, this is awesome! I've experimented with importing pkgsrc
> into bzr, but even with all the recent improvements, it's still
> no good. Quite a shame, I think. I've just been working with
> silly non-history-preserving branches. I use git at work and
> really hate it, but not so much as to prevent me from switching
> over for pkgsrc work :).
>
>>> They are not authoritative and are not meant to replace cvs,
>
> It's a good start. Maybe people will experiment with it and
> learn how we could be working.
>
>> indeed, since user need to be aware of a caveat: All $NetBSD$ tags
>> appear to be wrong. They have the value as of the checkin of each
>> version of each file, not the checkout, so they are always 1 version
>> behind. (I checked this on src/Makefile which shows this in cvs
>>
>> # $NetBSD: Makefile,v 1.274 2009/09/04 17:21:33 pooka Exp $
>>
>> and this in the git version:
>>
>> # $NetBSD: Makefile,v 1.273 2009/08/30 01:49:42 dyoung Exp $
>
> That's how it works in CVS. The keywords are expanded by your
> client in the working copy. Then the expanded form is committed
> when you commit. Thus, the repository is always one behind.
>
>> (There has been a very heated discussion among GIT people why keyword
>> expansion is supposed to be evil. They are not going to be convinced to
>> implement it. I am very annoyed by that.)
>
> They are evil. Evil evil evil evil. EVIL! No modern system
> supports them, nor are they likely, and we're all the better
> for it.
hg supports it
|
|
Re: git copies of cvs modules available
* Adam Hoka < adam.hoka@...> [2009-10-14 13:47]:
> On 10/14/09 04:44, Eric Gillespie wrote:
> >Rhialto< rhialto@...> writes:
> >>(There has been a very heated discussion among GIT people why keyword
> >>expansion is supposed to be evil. They are not going to be convinced to
> >>implement it. I am very annoyed by that.)
> >
> >They are evil. Evil evil evil evil. EVIL! No modern system
> >supports them, nor are they likely, and we're all the better
> >for it.
>
> hg supports it
These days, Git actually supports the expansion of $Id$ on checkout and
allows for implementing other stuff yourself, too; see gitattributes(5).
Holger
|
|
Re: git copies of cvs modules available
On Wed 14 Oct 2009 at 15:06:29 +0200, Holger Weiß wrote:
> * Adam Hoka < adam.hoka@...> [2009-10-14 13:47]:
> > On 10/14/09 04:44, Eric Gillespie wrote:
> > >Rhialto< rhialto@...> writes:
> > >>(There has been a very heated discussion among GIT people why keyword
> > >>expansion is supposed to be evil. They are not going to be convinced to
> > >>implement it. I am very annoyed by that.)
> > >
> > >They are evil. Evil evil evil evil. EVIL! No modern system
> > >supports them, nor are they likely, and we're all the better
> > >for it.
> >
> > hg supports it
>
> These days, Git actually supports the expansion of $Id$ on checkout and
> allows for implementing other stuff yourself, too; see gitattributes(5).
Yes, but the $Id$ that it supports is a hash value which is absolutely
meaningless to a human reader.
Why I want (cvs-like) $Id$ is that I can see at a glance which version a
file is, compare its version with that of another file, that sort of
things, without help from the VCS. Files seem to have a habit of
"escaping from" the VCS so saying "but you can just look up the hash
value in the VCS" are not very helpful.
(There is some extra functionality with $Format$ if you "export" a tree,
but that requires making another full copy and is therefore even more
expensive.)
The only real reason I have found behind the statement "keyword
expansion is evil" is "it is inefficient". The reasoning behind that is
that if you switch from one branch to another, it may need to change
keywords in files which it doesn't otherwise change. There may be after
all files which are identical in two branches but with a different
history for each. (Not that that sounds too likely, anyway). The
argument then is that it would have to touch every file to get these
cases right.
But the way around that seems to me that it is easy enough to find the
path through the revision graph from the revision on the first branch to
that on the second one. If a VCS is patch-based you have to do that
anyway but even if not it shouldn't be too expensive. You only have to
re-expand in those files that have edits anywhere on the path.
> Holger
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- You author it, and I'll reader it.
\X/ rhialto/at/xs4all.nl -- Cetero censeo "authored" delendum esse.
|
|
Keyword expansion (was Re: git copies of cvs modules available)
On 13-Oct-2009, at 10:44 PM, Eric Gillespie wrote:
> They are evil. Evil evil evil evil. EVIL! No modern system
> supports them, nor are they likely, and we're all the better
> for it.
Actually, bzr has support for keyword expansion too with the bzr-
keywords plugin:
https://launchpad.net/bzr-keywordsBrian.
--
"Amusement to an observing mind is study." - Benjamin Disraeli
|
|
Re: git copies of cvs modules available
On Tue, Oct 13, 2009 at 3:38 AM, S.P.Zeidler < spz@...> wrote:
> Dear all,
>
> htdocs, othersrc, pkgsrc, src and xsrc are now available as
> (bare) git repository copies at
> http://ftp.netbsd.org/pub/NetBSD/misc/repositories/git.
> These repositories are currently updated every 30 minutes.
>
*Wonderfull* ! Thanks a lot !
I will no longer have to keep a copy of that 7G cvsroot, finished also
hours lost waiting for an update to complete :/ humm, XXIth century
old tools... :)
Btw, how did the convertion occur ? I guess with git-cvsimport ? I
remind that several ,v files were corrupted/unparsable and keithp'
parsecvs was unable to work with them.
Can we consider this tree stable (ie. do real work on top of it), or
may it be recreated to say fix the Id issue or stuff like that ?
Thanks,
- Arnaud
|
|
Re: git copies of cvs modules available
On Oct,Monday 19 2009, at 12:14 AM, Arnaud Lacombe wrote:
> On Tue, Oct 13, 2009 at 3:38 AM, S.P.Zeidler < spz@...> wrote:
>> Dear all,
>>
>> htdocs, othersrc, pkgsrc, src and xsrc are now available as
>> (bare) git repository copies at
>> http://ftp.netbsd.org/pub/NetBSD/misc/repositories/git.
>> These repositories are currently updated every 30 minutes.
>>
> *Wonderfull* ! Thanks a lot !
>
> I will no longer have to keep a copy of that 7G cvsroot, finished also
> hours lost waiting for an update to complete :/ humm, XXIth century
> old tools... :)
>
> Btw, how did the convertion occur ? I guess with git-cvsimport ? I
> remind that several ,v files were corrupted/unparsable and keithp'
> parsecvs was unable to work with them.
Conversion was done by fromcvs tool. IT can do one time conversion and
incremental updates, too.
>
> Can we consider this tree stable (ie. do real work on top of it), or
> may it be recreated to say fix the Id issue or stuff like that ?
For now this tree should be stable, but it was done for testing to
found out if there can be some usage for git trees inside of NetBSD
users group.
Regards
Adam.
|
|
Re: git copies of cvs modules available
On Sun, October 18, 2009 7:06 pm, Adam Hamsik wrote:
> For now this tree should be stable, but it was done for testing to
> found out if there can be some usage for git trees inside of NetBSD
> users group.
For users outside of NetBSD, it's also useful. There's already a rough
DragonFly conversion of pkgsrc to git, just to avoid using CVS when we're
using git for the rest of the system:
http://gitweb.dragonflybsd.org/pkgsrc.git
|
|
Re: git copies of cvs modules available
2009/10/14 Rhialto < rhialto@...>:
> On Wed 14 Oct 2009 at 15:06:29 +0200, Holger Weiß wrote:
>> * Adam Hoka < adam.hoka@...> [2009-10-14 13:47]:
>> > On 10/14/09 04:44, Eric Gillespie wrote:
>> > >Rhialto< rhialto@...> writes:
>> > >>(There has been a very heated discussion among GIT people why keyword
>> > >>expansion is supposed to be evil. They are not going to be convinced to
>> > >>implement it. I am very annoyed by that.)
>> > >
>> > >They are evil. Evil evil evil evil. EVIL! No modern system
>> > >supports them, nor are they likely, and we're all the better
>> > >for it.
>> >
>> > hg supports it
>>
>> These days, Git actually supports the expansion of $Id$ on checkout and
>> allows for implementing other stuff yourself, too; see gitattributes(5).
>
> Yes, but the $Id$ that it supports is a hash value which is absolutely
> meaningless to a human reader.
Not that the CVS version is much more meaningful.
It somehow encodes the history of the file but it's only possible
because CVS branches are hopelessly static and don't reflect reality
(like merging branches or picking patches from branches and applying
them elsewhere). Sure, this is quite hard to do in CVS so it does not
happen often and that's why the version numbers seem somewhat
meaningful.
In fact the version numbers have about as much meaning as the git hash
number. You have to guess which repo they come from and look up that
version in that repo, and only then you see the history and context in
which you can compare. And should hope nobody applied a patch on the
file outside of the VCS magic because then the version written in the
file will be wrong.
>
> Why I want (cvs-like) $Id$ is that I can see at a glance which version a
> file is, compare its version with that of another file, that sort of
> things, without help from the VCS. Files seem to have a habit of
> "escaping from" the VCS so saying "but you can just look up the hash
> value in the VCS" are not very helpful.
When the file "escapes from" a VCS the version number is meaningless.
There is no context to which you can compare. If you can guess the
repo it came from there are things like gitweb where you input the
number and it shows you the commit. You cannot possibly get more than
that.
For me a file is identified by a hash of the actual file, not a
version number. You either have the same file or you don't. I can
write any version number I like into any file, I can have every file
version 42.
Thanks
Michal
|
|
Re: git copies of cvs modules available
At Tue, 27 Oct 2009 23:02:00 +0100, Michal Suchanek < hramrach@...> wrote:
Subject: Re: git copies of cvs modules available
>
> 2009/10/14 Rhialto < rhialto@...>:
> > Yes, but the $Id$ that it supports is a hash value which is absolutely
> > meaningless to a human reader.
>
> Not that the CVS version is much more meaningful.
Note the key phrase here is "human reader".
A CVS identifier number not really truly meaningful in a direct sense of
course, but it is easily recognisable, and an average human reader can
easily (i.e. on a glance) compare RCS/CVS/SCCS style version identifiers
without any real effort whatsoever.
That's just not possible with a long hash string.
> When the file "escapes from" a VCS the version number is meaningless.
Well, "meaningless" outside the VCS only in the most strict sense.
In day-to-day reality the simple-form RCS/CVS/SCCS version identifiers
can still work without effort for the _human_ reader when one is dealing
with RCS/CVS/SCCS-style central (authoritative) repositories.
Key here though is of course that with a central authoritative
repository you don't need a VCS "context" in which to compare the
simple-form RCS/CVS/SCCS style version identifiers. They are easy to
compare in any context, even without any access to the repository,
because for a given file they all originate from the same source.
Of course once it gets down to the assignment of real meaning to the
identifier, i.e. the kind of meaning I think you were actually talking
about, then you do effectively need the repository, especially with CVS,
because any branch numbers are meaningful only with the context of one
file and so you need the related tag identifiers to compare them with
any other files. However this use is far more rare in my experience.
Most commonly, especially outside the direct context of the VCS, humans
usually just want to see if the IDs are the same or not, perhaps with
some hint as to their relationship in time if they're not. This works
even if you don't have the entire original source file to look at,
eg. when you compare the output of "what foo.o", etc.
--
Greg A. Woods
Planix, Inc.
< woods@...> +1 416 218 0099 http://www.planix.com/
|
|
Re: git copies of cvs modules available
2009/10/28 Greg A. Woods < woods@...>:
> At Tue, 27 Oct 2009 23:02:00 +0100, Michal Suchanek < hramrach@...> wrote:
> Subject: Re: git copies of cvs modules available
>>
>> 2009/10/14 Rhialto < rhialto@...>:
>> > Yes, but the $Id$ that it supports is a hash value which is absolutely
>> > meaningless to a human reader.
>>
>> Not that the CVS version is much more meaningful.
>
> Note the key phrase here is "human reader".
>
> A CVS identifier number not really truly meaningful in a direct sense of
> course, but it is easily recognisable, and an average human reader can
> easily (i.e. on a glance) compare RCS/CVS/SCCS style version identifiers
> without any real effort whatsoever.
>
> That's just not possible with a long hash string.
>
>
>> When the file "escapes from" a VCS the version number is meaningless.
>
> Well, "meaningless" outside the VCS only in the most strict sense.
>
> In day-to-day reality the simple-form RCS/CVS/SCCS version identifiers
> can still work without effort for the _human_ reader when one is dealing
> with RCS/CVS/SCCS-style central (authoritative) repositories.
>
> Key here though is of course that with a central authoritative
> repository you don't need a VCS "context" in which to compare the
> simple-form RCS/CVS/SCCS style version identifiers. They are easy to
> compare in any context, even without any access to the repository,
> because for a given file they all originate from the same source.
>
> Of course once it gets down to the assignment of real meaning to the
> identifier, i.e. the kind of meaning I think you were actually talking
> about, then you do effectively need the repository, especially with CVS,
> because any branch numbers are meaningful only with the context of one
> file and so you need the related tag identifiers to compare them with
> any other files. However this use is far more rare in my experience
|
|
Re: git copies of cvs modules available
Hi,
On Tue, Oct 27, 2009 at 9:10 PM, Greg A. Woods < woods@...> wrote:
> ..., humans
> usually just want to see if the IDs are the same or not, perhaps with
> some hint as to their relationship in time if they're not.
well, as an heavy git user, what I want to know is if the source I'm
looking at are the same as the one who has an issue with the source.
With a SHA1, no matter on which repo I'll look at, I will have this
guarantee (minus an improbable collision). CVS doesn't provide this
basic guarantee that 2 same filename with the same CVS number check
out at different time are the same (data corruption or malicious
change). That is a serious flaw.
AFAIK, there is already a (few?) case of this is our CVS repository
(file which original version has been tempered with due to legal
issue, however that was wanted).
- Arnaud
|
|
Re: git copies of cvs modules available
2009/10/29 Arnaud Lacombe < lacombar@...>:
> Hi,
>
> On Tue, Oct 27, 2009 at 9:10 PM, Greg A. Woods < woods@...> wrote:
>> ..., humans
>> usually just want to see if the IDs are the same or not, perhaps with
>> some hint as to their relationship in time if they're not.
> well, as an heavy git user, what I want to know is if the source I'm
> looking at are the same as the one who has an issue with the source.
> With a SHA1, no matter on which repo I'll look at, I will have this
> guarantee (minus an improbable collision). CVS doesn't provide this
> basic guarantee that 2 same filename with the same CVS number check
> out at different time are the same (data corruption or malicious
> change). That is a serious flaw.
>
The hash git gives you is changeset hash (or something like that).
This changes every time you reapply the changeset to a different repo
or a different branch of the same repo and has nothing to do with file
hashes.
However, you can always make a hash of your file, and if you do
automagic expansion of stuff in the file might get in the way.
Thanks
Michal
|
|
Re: git copies of cvs modules available
* Michal Suchanek < hramrach@...> [2009-10-29 09:54]:
> 2009/10/29 Arnaud Lacombe < lacombar@...>:
> > On Tue, Oct 27, 2009 at 9:10 PM, Greg A. Woods < woods@...> wrote:
> >> ..., humans usually just want to see if the IDs are the same or not,
> >> perhaps with some hint as to their relationship in time if they're not.
> >
> > well, as an heavy git user, what I want to know is if the source I'm
> > looking at are the same as the one who has an issue with the source.
> > With a SHA1, no matter on which repo I'll look at, I will have this
> > guarantee (minus an improbable collision). CVS doesn't provide this
> > basic guarantee that 2 same filename with the same CVS number check
> > out at different time are the same (data corruption or malicious
> > change). That is a serious flaw.
>
> The hash git gives you is changeset hash (or something like that).
> This changes every time you reapply the changeset to a different repo
> or a different branch of the same repo and has nothing to do with file
> hashes.
Git stores the contents of files as blob objects which are referenced
via their SHA1 hash in just the same way as commit objects. For $Id$
expansion, the SHA1 of the blob object is used:
| When the attribute ident is set for a path, git replaces $Id$ in
| the blob object with $Id:, followed by the 40-character hexadecimal
| blob object name, followed by a dollar sign $ upon checkout.
[ gitattributes(5) ]
Holger
|
attachment0 (193 bytes) 