RE: feature request: git svn dommit --preserve-timestamps

["Randall S. Becker" <rsbecker@nexbridge.com>]

Somewhen near June 10, 2016 9:40 PM, Eric Wong wrote:
> Peter Münster <pmlists@free.fr> wrote:
> > On Tue, Jun 07 2016, Eric Wong wrote:
> > > Peter Münster <pmlists@free.fr> wrote:
> > >> It would be nice, if timestamps could be preserved when rewriting
> > >> the git-log.
> > >
> > > Unfortunately, last I checked (a long time ago!), explicitly setting
> > > revprops might require SVN administrators to enable the feature for
> > > the repo.
> >
> > Not the svn-log, only the git-log.
> 
> The git log after dcommit is tied to the SVN log, so git-svn can only reflect
> changes which appear in SVN.
> 
> 	Sidenote: The convention is reply-to-all on lists like
> 	this one which do not require subscription to post.
> 	It prevents the list from being a single-point-of-failure
> 	or censorship.
> 
> > > It's been a while and I'm not up-to-date with the latest SVN.
> > > Maybe there's a newer/easier way you could give us details about :)
> >
> > No, sorry. I don't care about the svn-log.
> 
> Unfortunately, you would have to care about svn log as long as SVN exists in
> your workflow and you need to interact with SVN users.
> 
> git svn tries hard to work transparently and as close to the behavior of the
> upstream SVN repo as possible.

Having had to deal with this in pure git without factoring in git svn, this seems to be is a matter of policy rather than technical requirement. Various customers of mine have decided that using the commit time as a uniform timestamp to be applied to all files pulled in the specific commit, is the way to go when doing continuous integration. The solution that we ended up with was a step in our Jenkins build jobs that would set the timestamp of all files associated with the specific commit to the time of the commit itself. Any commit not part of the commit that changed that state of the repository was untouched. This became arbitrarily complex when the job was impacted by multiple commits, but the general consensus of those who made the decisions was to apply all timestamps associated with all commits, in order, of application (Jenkins seems happy to deal with this part), so that the files do keep relatively sane from a build perspective. Personally, I am relatively happy with this solution, even if it adds a huge amount of time to the build - generally more than the build itself - so that timestamps are "sane". Doing it for straight clones does not seem worth it, because timestamps don't appear to matter, policy wise, unless official builds are being done. It may be worth considering that in the discussion. 

My comments are just based on a production perspective, rather than development, so I ask forgiveness for any red-herrings that may be involved.

Cheers,
Randall

-- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(211288444200000000)
-- In my real life, I talk too much.