rsync - Nov 2007 - Assorted concerns about git repository

Wayne,

I have a few more concerns about the git repository:

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.  You also removed "rsync.1" even from revisions before it
became
a file generated from "rsync.yo"; can this possibly be intended?

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/ .
A user will get the generated files corresponding to the latest trunk no
matter what branch or point in time she has seeked to, with no warning
about the mismatch.  It would be better to offer a separate branch
containing the generated files, or if "./configure && make"
really must
work on the default branch without autotools, use "*_shipped" files
like
the Linux kernel source tree does.

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.

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.

5. How will you mark the revisions of the branches that were provided
with a particular rsync release?  (This is the "nesting" issue I
mentioned in my git slides.)  You could tag each branch at each release,
but that would result in a *lot* of tags and I think it would be cleaner
to have a single object representing the release.  One way to get that
is to make a tree object containing the commits for the trunk and all
the branches as children and then tag this tree object (echoes of
Subversion); git doesn't go out of its way to make this usage easy, but
it would work.

Matt

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
rsync manually.
> 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
that.
> 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:

    http://rsync.samba.org/ftp/rsync/patches/

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.

..wayne..