Assorted concerns about git repository
wayned at samba.org
Wed Nov 28 23:33:07 GMT 2007
On Sat, Nov 17, 2007 at 03:48:10PM -0500, Matt McCutchen wrote:
> 1. It looks like you retroactively removed all generated files from
> the history. This may inconvenience a user who seeks to an older
> version of the source code and lacks the magic "configure" to help
> regenerate the files.
The main purpose for the generated files being in CVS and/or git
(including the magic "configure" script) is to make the build farm work.
When a human checks out the files from git, I see no problem requiring
them to build the generated files themselves -- an initial run of the
./prepare-source script will take care of it (or manually running
autoconf and autoheader if prepare-source isn't around). I have updated
the download page to mention this preparatory step. Each release tar
will still include generated files, as usual.
> You also removed "rsync.1" even from revisions before it became
> a file generated from "rsync.yo"; can this possibly be intended?
That was a mistake that I am going to try to correct at some point.
Thanks for pointing that out.
> 2. I think it is a bad idea to have the rsync build system download
> generated files from rsync://rsync.samba.org/rsyncftp/generated-files/ .
That copy is for old build-farm systems that don't have what it takes to
build the configure.sh file. The latest code has been modified to only
allow a build-farm system to execute that, since (as you noted) those
files only pertain to the very latest release. Folks without the
necessary autoconf/yodl tools can also decide to make use of this dir
when grabbing the very latest dev version, but they'll need to run the
> 3. It looks like you removed patches/ from the history. I think it is
> valuable to have the history of the branches from before they became
> real branches.
I didn't want all the patch (side-branch) commits cluttering up the
master branch's release log. This history can be accessed in the old
CVS archive, which is going to remain available. It would be nice
to create a script that could translate the CVS commits to the patches
into branch commits in a git branch, but I haven't tried to look at
> 4. Why do you recommend that people run "git-set-file-times"? I would
> like to see more explanation before I mess with my source files' mtimes.
The web page mentions that it sets the file times to their time of last
modification. I want an INITIAL checkout (clone) to always set each
file's time to the time of its last change (not the checkout time), and
this script works-around git's deficiency in this area. This makes a
fresh checkout the same no matter when it is cloned (though two
checkouts would diverge in their mtime settings as they are
incrementally updated after that point).
> 5. How will you mark the revisions of the branches that were provided
> with a particular rsync release?
I haven't fully worked out everything pertaining to the git handling of
the patch branches for a release. I'm currently putting the set of
patch diffs that represent the state of each patch branch at the time of
a release into a separate patch tar file. The patches for the dev
version are also available as diffs at this URL:
How the branches get tagged in git I'll need to work out a bit more.
Thanks for your tagging suggestion. I'll look into it.
More information about the rsync