Progress towards shipping 2.40

[Eric S. Raymond-2]

As promised, I have fixed Jeff Francis's multisession bug.  We're
waiting on Chris and Gary now.

Developers should be aware that ssh login to berlios is still down, but
SVN is working.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Ed Wildgoose-2]

Eric S. Raymond wrote:
> As promised, I have fixed Jeff Francis's multisession bug.  We're
> waiting on Chris and Gary now.
>
> Developers should be aware that ssh login to berlios is still down, but
> SVN is working.
>  

A good time to "upgrade" to git/mercurial/bazaar ? (Personally I know
git best so I vote for that..)

Ed W
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Ed W <lists@...>:
> A good time to "upgrade" to git/mercurial/bazaar ? (Personally I know
> git best so I vote for that..)

Chris and I both want to move the project to to a 3G VCS, but this is
*not* something I'm going to combine with a site migration, even in
non-emergency conditions.  One problem at a time!
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Ed Wildgoose-2]

Eric S. Raymond wrote:

Ed W lists@...:
  

A good time to "upgrade" to git/mercurial/bazaar ? (Personally I know 
git best so I vote for that..)
    

Chris and I both want to move the project to to a 3G VCS, but this is
*not* something I'm going to combine with a site migration, even in 
non-emergency conditions.  One problem at a time!
  

Not an advocation either way, but I have migrated quite a few simple SVN projects up to github and largely speaking it's a fairly painless process.  It depends on your requirements to have an absolutely perfect migration straight away, but the actual commits migrate one to one, the issues are largely with:

- matching commiter svn names with an email address that git uses (easy if you have few committers)
- branches - generally fine if it's a trunk/release kind of setup. I found a few screwy things where sometimes the source svn repo appeared corrupt, but no one really noticed before
- Line endings. Nothing bad happens if you use windows line endings, but all the git tools assume unix line endings and it tends to diff less than optimally or show a bogus changed file if you leave a bunch of windows line endings AND certain options are set at the users end in their .gitconfig.  Doesn't worry most people, but I find it irritating.  You can't change old commits, but you can do a quick fix and commit it as a trunk change


One of the nice things about git is that you can actually rewrite the whole repo and the tree after the event (if you wish).  commands like "git rebase" can let you do super funky things (in general don't do them though) such as completely re-ordering commits, merging them, splitting them out, dropping whole commits, all with an interactive interface!

The punchline really is that if you are dropping legacy SVN users (if!) then really the job is just to get all the commits into the new repo - even after the fact you can jiggle them about and recreate any previous state (a branch in git is really just an ordered series of commits - you can grab pretty much any bunch of commits in any order and call it a branch...)

Can't comment on mecurial/bazaar, for sure they are probably as good, but don't personally have any experience.

If you would like someone to do a trial conversion, say to github (which isn't a bad place just to park a git tree and wiki) then let me know and I will try and help - I believe others have already done this to various extents though.

Now my 2p: If you try the conversion and it looks straightforward and nothing obviously breaks, personally I would suggest you just do the migration at the same time as you jump ship...  Keep a copy of the old svn repo for historical purposes/backup

Good luck

Ed W

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Ed W <lists@...>:
> Not an advocation either way, but I have migrated quite a few simple SVN  
> projects up to github and largely speaking it's a fairly painless  
> process.  It depends on your requirements to have an absolutely perfect  
> migration straight away, but the actual commits migrate one to one, the  
> issues are largely with:
>
> - matching commiter svn names with an email address that git uses (easy  
> if you have few committers)

Hm.  How does git svn handle this issue?

> - branches - generally fine if it's a trunk/release kind of setup. I  
> found a few screwy things where sometimes the source svn repo appeared  
> corrupt, but no one really noticed before

We have no branches.  We do have tags.  One question I've been curious
about is whaty svn-to-git conversion does to SVN tags.  Do they turn into
branches, or do they turn into symbolic revision name a la RCS/CVS?
I would consider the latter preferable.

> - Line endings. Nothing bad happens if you use windows line endings, but  
> all the git tools assume unix line endings and it tends to diff less  
> than optimally or show a bogus changed file if you leave a bunch of  
> windows line endings AND certain options are set at the users end in  
> their .gitconfig.  Doesn't worry most people, but I find it irritating.  
> You can't change old commits, but you can do a quick fix and commit it  
> as a trunk change

Not an issue.  We have no Windows line endings.

> One of the nice things about git is that you can actually rewrite the  
> whole repo and the tree after the event (if you wish).  commands like  
> "git rebase" can let you do super funky things (in general don't do them  
> though) such as completely re-ordering commits, merging them, splitting  
> them out, dropping whole commits, all with an interactive interface!

I have a script in the gpsd repo at devtools/editcomment that I can use to fix
typos in old revision comments.  How would you implement that in git?  If I
were to do such a tweak, what would thge implications be for push-pull-merge
operations?

(Note: The current version of the SVN repo, and sanooj's git mirror, has all
known typos fixed.  I'd like to preserve the capability to do this,
however, as I typo a lot...)

> If you would like someone to do a trial conversion, say to github (which  
> isn't a bad place just to park a git tree and wiki) then let me know and  
> I will try and help - I believe others have already done this to various  
> extents though.

Sanooj maintains an unofficial git mirror now, which was a good thing
during the berlios site outage.

> Now my 2p: If you try the conversion and it looks straightforward and  
> nothing obviously breaks, personally I would suggest you just do the  
> migration at the same time as you jump ship...  Keep a copy of the old  
> svn repo for historical purposes/backup

I'd do the latter anyway.  I'm still disinclined to combine a version-control
changeover with a site migration, unless we're moving to a site dedicated
to a single VCS such as github or bitbucket.

Ed: thanks, by the way, for listing these issues. I think none of them are
going to bite us, but I found your roundup of them very informative.

This is probably a good point at which to mention that yesterday I
joined the development team for Savane, the hosting engine that powers
gna.org.  I'll divagate on my reasons in a separate post.  The point
here is that gna.org just got a lot more attractive; I even have root
access to the live Gna! host now.

(Yes, Chris, this means that as of now I *am* a gna.org admin... :-)
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Greg Troxel]

"Eric S. Raymond" <esr@...> writes:

> I'd do the latter anyway.  I'm still disinclined to combine a
> version-control changeover with a site migration, unless we're moving
> to a site dedicated to a single VCS such as github or bitbucket.

I concur - while I realize the advantages of 3G VCSes:

  there's no need to rush and combine things that don't need combining,
  as Eric points out

  gpsd is not having problems from using svn.

  By now, everyone in the open source world knows how to use svn.  newer
  systems are still a barrier.  For example, I consider myself clueful
  in the open source world, but pretty much everything I work on is in
  cvs or svn.  The exception is quagga, and various things, git being
  one of them, but mostly lack of time, have kept me from really
  learning to deal.  This isn't a big deal, but it's significant, and
  those close to the project that already know git/whatever often seem
  to overlook it.


_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Greg Troxel <gdt@...>:
>   gpsd is not having problems from using svn.

That's not quite true.  Chris and I aren't contemplating 3G VCSes
because they're the new hotness, we are contemplating them because
being able to do commits without the net and merge to the master repo
later is really useful.  Especially for gpsd, with contributors on
places like oil tankers in mid-ocean. :-)

>   By now, everyone in the open source world knows how to use svn.  newer
>   systems are still a barrier.

But only a minor one, and this dev group is both small and more than
averagely capable.  On my other main project, Wesnoth, moving away from SVN
would be a big deal, as rhe dev group is large and partly composed of
artists and musicians and campaign designers who are not programmers.
Here, I'm not worried about it.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

Eric S. Raymond wrote:

> Ed W <lists@...>:
>> Not an advocation either way, but I have migrated quite a few simple SVN  
>> projects up to github and largely speaking it's a fairly painless  
>> process.  It depends on your requirements to have an absolutely perfect  
>> migration straight away, but the actual commits migrate one to one, the  
>> issues are largely with:
>>
>> - matching commiter svn names with an email address that git uses (easy  
>> if you have few committers)
>
> Hm.  How does git svn handle this issue?

You can define a translation file that maps SVN users to git user names
and email addresses (see http://github.com/guides/import-from-subversion).

>> One of the nice things about git is that you can actually rewrite the  
>> whole repo and the tree after the event (if you wish).  commands like  
>> "git rebase" can let you do super funky things (in general don't do them  
>> though) such as completely re-ordering commits, merging them, splitting  
>> them out, dropping whole commits, all with an interactive interface!
>
> I have a script in the gpsd repo at devtools/editcomment that I can use to fix
> typos in old revision comments.  How would you implement that in git?  If I
> were to do such a tweak, what would thge implications be for push-pull-merge
> operations?

Generally, the history is fixed at the moment you push it. This does not
mean that you can't add a -f flag to the next push, but if someone
pulled in the meantime, they'll have to merge.

However, if you fix the typos before pushing (either with an amended
commit if you note the error immediately after committing, or with an
interactive rebase), nobody will see that there was ever a typo.

HTH

Beat Bolli

--
mail: echo '<bNbolOli@...>' | tr -d '[A-S]'
pgp: 0x506A903A; 49D5 794A EA77 F907 764F  D89E 304B 93CF 506A 903A
gsm: 4.7.7.6.0.7.7.9.7.1.4.e164.arpa
icbm: 47.0452 N, 7.2715 E
http: www.drbeat.li

"It takes love over gold, and mind over matter" -- Dire Straits



_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Ed Wildgoose-2]

Eric S. Raymond wrote:

Greg Troxel gdt@...:
  

  gpsd is not having problems from using svn.
    

That's not quite true.  Chris and I aren't contemplating 3G VCSes
because they're the new hotness, we are contemplating them because
being able to do commits without the net and merge to the master repo
later is really useful.  Especially for gpsd, with contributors on
places like oil tankers in mid-ocean. :-)
  

Actually once you start using git I think you will be surprised.  It's not really the distribute bit which is cool, it's more that it gives you the ability to run in 5 different directions trying stuff, THEN at a later stage to come back and actually do something useful with all of that.  Yes in theory SVN has branches, but hands up anyone who has actually used them? 

So for example if you were hacking on gpsd with some new idea you would just branch and code.  Then if someone emailed a critical patch you would just switch back to the live branch, check in the change, test and release.  Then if you suddenly noticed some great idea on live you would branch again and quickly hack away and commit for later study (call all these hack branches "wip_something").  Now you switch back to your original hacking branch and decide to hack on, but you want to see all changes based on trunk, now git is smart enough to rebase all your changes onto trunk and if necessary it will rewrite any of your commits if for example you partially included one commit in another one.  Finally switch back to master and just cherry pick bits of commits from various wip branches (literally just pick bits out of any branch) and off you go

So that all sounds theoretical - how does it help in practice.

Well as a user I can:

- Submit a bunch of changes I have locally.  If you accept *some* of those changes, then when I rebase my local tree it (optionally) actually rewrites my commits so that I just see the outstanding changes that you didn't accept as individual commits.  In this way I can easily maintain a "changes_to_push_upstream" branch and track what I send you and which bits you haven't yet taken, eg need re-work

- Maintain an independent branch with some local patches that work for me.  This is not possible to do with vanilla svn!  So I can source control my own patches AND I can merge in all the upstream patches.  At any time I can see what's different in my tree and upstream.  If any of my local patches no longer make sense it's easy to track individual commits even from years ago and say reverse them from my local tree (even though they may now be themselves not cleanly apply to the trunk, git can figure out what to do, including seeing through renamed files, etc!)


Being able to work offline is actually a relatively small subset of the cool stuff you can now do!

  By now, everyone in the open source world knows how to use svn.  newer
  systems are still a barrier.
    

But only a minor one, and this dev group is both small and more than
averagely capable.

Nah, actually I do agree.  Notice in my emails I commented that I don't know mercurial/bazaar - both have their own proponents, I just don't know them myself...

I think just like svn you can learn the basics fairly easily to at least get some work done.  I would agree getting to know the advanced stuff is a barrier with any tool.  That said I think some basic git experience is worth everyone gaining because so many opensource projects are using it that at least being able to checkout some repository is practically a given

I have pretty much gone the other way - these days I can hardly remember how to do much more than check-in/out of svn and probably given half a chance I would just use git-svn and be done with it...

I found this book excellent (get the ebook say)
http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git

Also there is at least as good documentation on the git website (which is obviously free) and you have a selection of graphical tools available for nearly all platforms (personally I only use the command line except for visualising branches)

Good luck

Ed W

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Ed Wildgoose-2]

Eric S. Raymond wrote:

Ed W lists@...:
  

Not an advocation either way, but I have migrated quite a few simple SVN  
projects up to github and largely speaking it's a fairly painless  
process.  It depends on your requirements to have an absolutely perfect  
migration straight away, but the actual commits migrate one to one, the  
issues are largely with:

- matching commiter svn names with an email address that git uses (easy  
if you have few committers)
    

Hm.  How does git svn handle this issue?
  

As Greg says you use a mapping file, eg something like this is a good import "script"

git-svn clone -A ./git.authors --stdlayout  svn://blah

- branches - generally fine if it's a trunk/release kind of setup. I  
found a few screwy things where sometimes the source svn repo appeared  
corrupt, but no one really noticed before
    

We have no branches.  We do have tags.  One question I've been curious
about is whaty svn-to-git conversion does to SVN tags.  Do they turn into
branches, or do they turn into symbolic revision name a la RCS/CVS?
I would consider the latter preferable.
  

Git has cheap branching, so everything is a branch.  That said I believe it has some makeup to gloss over certain types of branches and call them "tags", but in practice they all behave like branches.  I would need to do a trial import to see what the importer does without tweaking, but git-svn is in massive production use around the world so imagine anything you want it to do is possible...

Note pretty much anything can be treated as a branch in git.  So for example you can take a commit reference and use that a "branch" to checkout, or diff against, or whatever...  Unbelievably powerful really

I have a script in the gpsd repo at devtools/editcomment that I can use to fix
typos in old revision comments.  How would you implement that in git?  If I
were to do such a tweak, what would thge implications be for push-pull-merge
operations? 
  

Git will let you rewrite history as much as you like - if you so desire...

However, beware that once someone else pulls down your changes then "editing" a commit is going to cause them pain to sync back with you.  What this means in practice is that you tend to work like:

- Create a branch, hack, hack, commit lots and tend to commit in smaller bite sized chunks than you would with svn (git gives you tools to commit even just *parts* of the diff to files!)
- If you have been hacking a lot then create a new merge branch and use this to bring trunk and your hack branch to a release quality
- Switch to trunk and pull in either all your merge branch, or alternatively just cherry pick bits from any other branch including remote branches pulled in from other contributors
- This is all done on your local repo, once you are happy that trunk is how you want it then you push it up to your distribution server.  From that point you prefer never to edit a commit - instead you will only send new commits

So the point is you have a lot of new tools to branch and code in much smaller chunks locally.  This gives you a much higher commit quality (well at least for me it's transformed my commits from mega chunks to smaller bite sized things which each tell a story).  But once you push changes public you don't edit them again

Sanooj maintains an unofficial git mirror now, which was a good thing
during the berlios site outage.
  

I suspect you should just evaluate his repo for quality and then switch to that if it's good?

Keep a copy of the old  
svn repo for historical purposes/backup
    

I'd do the latter anyway.  I'm still disinclined to combine a version-control
changeover with a site migration, unless we're moving to a site dedicated
to a single VCS such as github or bitbucket.
  

Sounds safe - however, I think if you don't change you never will... I personally would argue that everyone is going to go through a whole bunch of upheaval when you move, so you might as well keep going and break more...

I could be wrong, but I always found changing the svn repo url a bit of a pain... I think tortoisesvn had a utility to do it, but I wouldn't personally know how to do it from the commandline.

My 2p would be that since everyone has to update their RPM/ebuild's, plus fix their svn repos, etc, etc - why not go the whole hog and do all your pent up changes in one go?  Presumably people are more forgiving of breakages right now on the grounds that everything is up in the air at the moment?

However, since you now picked a destination for the site - does gna support git?  Never looked myself?  This alone probably determines your choices quite a bit?

My 2p is still that since you are changing never everything you should continue to spoil everyone's day and pick your final VCS system also...

Good luck

Ed W



_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Ed W <lists@...>:
>> Sanooj maintains an unofficial git mirror now, which was a good thing
>> during the berlios site outage.
>>  
>
> I suspect you should just evaluate his repo for quality and then switch  
> to that if it's good?

If we go with git, that's certainly  a possibility.

> However, since you now picked a destination for the site - does gna  
> support git?  Never looked myself?  This alone probably determines your  
> choices quite a bit?

The bad news is that gna presently supports only CVS, SVN, and Arch.

The good news is...having been given root access to the gna.org server,
I can fix that :-)
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Bernd Zeimetz]

Ed W wrote:

> Eric S. Raymond wrote:
>> Ed W <lists@...>:
>>  
>>> Not an advocation either way, but I have migrated quite a few simple
>>> SVN  projects up to github and largely speaking it's a fairly
>>> painless  process.  It depends on your requirements to have an
>>> absolutely perfect  migration straight away, but the actual commits
>>> migrate one to one, the  issues are largely with:
>>>
>>> - matching commiter svn names with an email address that git uses
>>> (easy  if you have few committers)
>>>    
>>
>> Hm.  How does git svn handle this issue?
>>  
>
> As Greg says you use a mapping file, eg something like this is a good
> import "script"
>
> git-svn clone -A ./git.authors --stdlayout  svn://blah
>
>
>>> - branches - generally fine if it's a trunk/release kind of setup. I
>>> found a few screwy things where sometimes the source svn repo
>>> appeared  corrupt, but no one really noticed before
>>>    
>>
>> We have no branches.  We do have tags.  One question I've been curious
>> about is whaty svn-to-git conversion does to SVN tags.  Do they turn into
>> branches, or do they turn into symbolic revision name a la RCS/CVS?
>> I would consider the latter preferable.

During the conversion svn tags *and* branches end up as branch in git as tags in
svn are no real tags - they're just another copy of code where you can commit to.

> Git has cheap branching, so everything is a branch.  That said I believe
> it has some makeup to gloss over certain types of branches and call them
> "tags", but in practice they all behave like branches.

No, a tag is a real tag, not as in svn a copy of a directory. In git a tag
points to one commit id. While you're able to checkout the commit the tag points
to, you can't add additional commits to the tag - you'd have to create a branch.
but you're able to move the tag to a different commit if you really want to.

>  I would need to
> do a trial import to see what the importer does without tweaking, but
> git-svn is in massive production use around the world so imagine
> anything you want it to do is possible...

I've using git-svn for a several months to track the gpsd development,
definitely not a problem to import the tree. I could even push it online
somewhere and keep it updated by a cron job.



--
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
                   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Bernd Zeimetz <bernd@...>:
> No, a tag is a real tag, not as in svn a copy of a directory. In git
> a tag points to one commit id. While you're able to checkout the
> commit the tag points to, you can't add additional commits to the
> tag - you'd have to create a branch.  but you're able to move the
> tag to a different commit if you really want to.

That's the behavior I'd prefer if we ever do an official conversion.

> I've using git-svn for a several months to track the gpsd development,
> definitely not a problem to import the tree. I could even push it online
> somewhere and keep it updated by a cron job.

Sanooj is already doing this, and it was a good thing.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Bernd Zeimetz]

Eric S. Raymond wrote:

> Bernd Zeimetz <bernd@...>:
>> No, a tag is a real tag, not as in svn a copy of a directory. In git
>> a tag points to one commit id. While you're able to checkout the
>> commit the tag points to, you can't add additional commits to the
>> tag - you'd have to create a branch.  but you're able to move the
>> tag to a different commit if you really want to.
>
> That's the behavior I'd prefer if we ever do an official conversion.
>
>> I've using git-svn for a several months to track the gpsd development,
>> definitely not a problem to import the tree. I could even push it online
>> somewhere and keep it updated by a cron job.
>
> Sanooj is already doing this, and it was a good thing.

Ok, then there is a second one now :)
http://git.debian.org/?p=users/bzed/gpsd.git;a=summary


--
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
                   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev