Skip to Content.
Sympa Menu

freetds - Re: [freetds] git advice

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddy77 AT gmail.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] git advice
  • Date: Mon, 12 Mar 2012 18:31:33 +0000

2012/3/12 Craig A. Berry <craigberry AT mac.com>:
> On Mar 11, 2012, at 3:47 PM, James K. Lowden wrote:
>
>> On Sat, 10 Mar 2012 17:56:15 -0500
>> "James K. Lowden" <jklowden AT freetds.org> wrote:
>>
>>> what is the best way to get the latest HEAD and branch code?
>>
>> Thanks to you both.  Tell me if this is sane.
>>
>> 1.  I ran "git clone" to create a local repository.
>> 2.  Each night, I'll run
>> 2a.   "git pull" to update the local repository
>> 2b.   For each branch (currently "master" and "Branch-0.91")
>
> I would use something to name the branch other than the fact that it's a
> branch.  Maybe "maint-0.91" or "release-0.91" or "stable-0.91" or
> something.  Though maybe this is part of the conversion from CVS and is
> already a done deal.
>
>>  2b1  git clean
>>  2b2  git checkout $BRANCH
>>  2b3  next branch if revision number unchanged
>>  2b4  autoconf etc. to make tarball publish publish
>>
>> To test the revision number, I use
>>
>> oak[freetds.git]$ for BRANCH in master Branch-0_91
>> do
>>       git show-branch \
>>       | awk -F '[][~]' "/${BRANCH}/ { print \$3,\$2 }" \
>>       | sort -rn | head -1
>> done
>>
>> yielding:
>>
>>       275 master
>>       46 Branch-0_91
>>
>> The version numbers then become:
>>
>>       freetds-0.92.dev.275
>>       freetds-0.91.46
>
> That should work.  But it might just be simpler to use the output of "git
> describe."  On the blead branch of the Perl main repository that currently
> looks like:
>
> % git describe
> v5.15.8-91-gacdbe25
>
> where the most recent tag on the branch is v5.15.8 indicating (fairly
> obviously I hope) the 5.15.8 release, and we're 91 commits after that tag,
> and the short version of the SHA1 commit id is acdbe25 (the "g" preceding
> the SHA1 is for git, I guess).  The SHA1 clinches the deal in making it
> completely unambiguous what we have since someone else in some other branch
> or some other repository could also be 91 commits since the same tag but
> with a different commit history.
>
> Now, the reason git describe doesn't currently work on the freetds
> gitorious repository is that there are no tags, thus no way for it to
> retrieve the most recent tag on a branch.  I consider that a defect in the
> conversion from CVS.  I'm not sure how the conversion was done or if there
> is a better way.  On the other hand, there aren't really *that* many
> releases, so it wouldn't be too arduous to do "git tag" a handful of times,
> once for each release.
>

?? quite strange, perhaps git-cvsimport does not convert tags?

I'll generate everything again if needed!!!

>
>> SONAMEs and tarball names will be similar.
>>
>> Anyone wanting to know the date can consult the repository or look at
>> the top of ChangeLog.  (Some documentation would doubtless help.)
>>
>> The monotonically incrementing version number is more informative than
>> the date:  If you hold version X and see current is version Y,
>> then Y - X tells you how many commits transpired meanwhile.  That's more
>> important than the date the version was produced.
>
> There aren't really monotonically increasing anything in git, but it's a
> useful fiction to preserve since human brains just don't do SHA1s or wend
> their way through directed acyclic graphs very easily.  But be aware that
> someone else could have a private branch where Z - X is the same distance
> as your Y - X.  One of the main points of a DVCS is parallel development,
> but there needn't be any preservation of that parallelism in the
> authoritative repository unless people want it for some reason.
>
>> For the purpose of generating the tarball ISTM I don't need a separate
>> working directory.  (I might for day-to-day use; like Frediano, I also
>> don't want to lose files I haven't checked in.)  The tarball is
>> generated; the next day any unversioned/modified files are purged by
>> "git clean".
>>
>> This process is significantly simpler than the one I use today.
>> Because CVS has nothing like a repository version number, I needed to
>> keep "yesterday's" MD5 (of the whole tree) to compare with today's
>> checkout.
>>
>> Expect to see git-produced tarballs tonight.
>>
>>       Issues
>>       ------
>>
>> 0.  Any concerns, questions, or suggestions with the above.
>>
>> 1.  Signore Ziglio, prego, could I have commit rights to the
>> repository? I'm jklowden on gitorious.  I will email the @freetds.org
>> alumni to advise them of the switch.
>>
>> 2.  How do we coordinate the switch from cvs?  Do we just name, say,
>> March 15 "Flag Day", and begin using git exclusively from that day
>> forward? Beware Caesar the Ides of March!
>>
>> 3.  Am I correct that we no longer need worry about a backup of the
>> repository, insofar as the one generating the tarballs is an exact copy
>> of what's on gitorious?
>>
>> 4.  Would it be wise to also use the overnight process -- perhaps not
>> *the* overnight process, perhaps another -- to synchronize gitorious
>> with github?  ISTM that would provide a good backup in the event of,
>> ahem, a security exploit or a man-made natural disaster like the one
>> that befell CVS on sf last year.
>>
>> --jkl
>>
>> _______________________________________________
>> FreeTDS mailing list
>> FreeTDS AT lists.ibiblio.org
>> http://lists.ibiblio.org/mailman/listinfo/freetds
>
> ________________________________________
> Craig A. Berry
> mailto:craigberry AT mac.com
>
> "... getting out of a sonnet is much more
>  difficult than getting in."
>                 Brad Leithauser
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds




Archive powered by MHonArc 2.6.24.

Top of Page