[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fink-devel
Subject:    Re: [Fink-devel] using Git/SVN to manage .info files in local/ tree?
From:       Charles Lepple <clepple () gmail ! com>
Date:       2009-02-01 16:49:41
Message-ID: 4EABADB6-EFE4-4ACD-BA0E-CEF14A6C0934 () gmail ! com
[Download RAW message or body]

Executive summary: using Git, with three separate repositories. See  
below for details.

On Jan 3, 2009, at 10:40 PM, Charles Lepple wrote:

> Note: if you thought this was going to be a rant about keeping info
> files in CVS, sorry to disappoint you.
>
> I have been keeping .info files for my packages in my own SVN
> repository for some time now, and IMHO things are working pretty well.
>
> The one thing that I think could use a little improvement is tracking
> when versions have been pushed from my local directory to unstable,
> and from unstable to stable (or when another maintainer commits a
> change to CVS, and I blindly overwrite that with local changes when
> upstream releases a new version).
>
> Has anyone set up something like this, where you can easily summarize
> what packages need to be tested, then promoted? (I know there is
> something like this on the PDB for all packages, but I figure this
> could most easily be tracked locally, especially since the PDB has no
> concept of my local/ directory, and takes some time to update.)
>
> I know just enough about Git to be dangerous, so if you have more
> git-fu please shoot holes in this idea: stable, unstable and local are
> all Git repositories (with appropriate ignore rules for both CVS
> metadata and packages which I don't maintain). The unstable repository
> is cloned from local, and both are seeded with the unstable tree from
> CVS (similarly, stable is cloned from unstable, but with the actual
> contents imported from CVS).

The above setup is what I use. Basically, each one only tracks the  
files I maintain, so they all have a gigantic .git/info/exclude file  
that I generated from the list of untracked files in 'git status'.

The trick here is that to maintain the status quo for stable (when  
packages have been updated in unstable), you need to clone the  
unstable tree into a temporary directory, but then move the .git file  
into the real stable/ directory, and make a bunch of commits that are  
essentially a step backwards in time ("un-committing" the updates  
that were made in unstable), so that the Git representation of stable  
matches CVS.

Later, when moving a package update from unstable to stable, you  
would basically undo those commits.

If I were not trying to keep the SVN history, I would just import  
stable into Git, clone that for unstable, and commit the differences  
between stable and unstable (as seen in the unstable directory).

> A typical package update might involve the following steps:
>
> 1) fink selfupdate-cvs
> 2) cd unstable; git commit -a [cvs -> git]
> 3) merge unstable -> local [git (+cvs changes) -> git]
> 4) hack in local; commit [git]
> 5) merge local -> unstable [git -> git; git -> cvs]

This workflow seems to do the trick (annotated with the data flow). I  
noticed that one of my packages was updated with the new PatchFile  
syntax, so I used that as a testcase for an external modification.  
The commit in step 2 gets the change into unstable/.git, and I can  
then go into local and run 'git pull' to move that into local.

While this is overkill for such a small change, it would make sure  
that things like the pangocairo update would be merged properly with  
works-in-progress.

With liberal use of 'git fetch' instead of 'git pull', I can easily  
see in 'git status' whether something is newer in local than in  
unstable.

Another potential advantage here is that you could do collaborative  
maintenance of a package without running into the limitations of CVS  
(e.g. having to manually sync between experimental/ and unstable/).

I haven't finished setting up gitweb or anything like that, but if  
anyone is interested in taking a look at how the repositories are  
structured, email me off-list and I will let you know where to clone  
from.

-- 
Charles Lepple
clepple@gmail




------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
[prev in list] [next in list] [prev in thread] [next in thread]