Re: import files preserving timestamps

Hello Erik (Stephan, Mark, Henrik, Liviu, Ryan)

Herewith a few questions and comments on the thread
"import files preserving timestamps", accessible via:
http://subversion.tigris.org/servlets/BrowseList?list=users&by=thread&from=658877

1. Erik, can you be more explicit about the "new design"
   effort which would provide an easy way to support the
   preservation/management of timestamp information in
   SVN? You say:
   http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=78362

   "... we're trying to work out a new structure for our
   working copy library. The new design should at least
   provide an easy way to support this request - not
   saying the first incarnation will actually implement it."

   - Who is "we" in this sentence?
   - Can you provide URIs for the discussion supporting
     this new design effort?

2. Can you be more specific about the projected timeframes
   for work on the new design, where (you say) "we intend
   to rewrite the working copy code"? As you know, user requests
   for SVN timestamp preservation support go back to 2001, and
   the repeated declarations "maybe later... not yet high
   on the developers' priority list" may justifiably be
   understood, after all these years, as "perhaps never"
   rather than just "not any time soon." You repeat the
   declaration here:

   "I think Subversion has enough feature requests outstanding
    which are generally considered 'more important' than
    versioning of timestamps."

3. I agree with Erik that it's "a hairy topic" that needs to
   address several use cases, based upon clear articulation
   of requirements and features. I have compiled substantial
   information about user requests and requirements [1]:

   "Once more: Subversion and file modification time (mtime)"
   http://svn.haxx.se/users/archive-2008-03/0462.shtml

   It's a very lengthy memo, describing one use case in some
   detail, together with commentary on issue #1256. Excerpts
   from many of the 400+ referenced URIs (postings) are provided,
   together with a few crude/raw statistics, hastily estimated
   -- like, over one hundred (100) different users who have provided
   use cases, analysis, design suggestions, sample
   patch/workaround code, and other commentary.

   For the one use case documented, I am in the same position as
   many who have attested that they simply cannot use Subversion
   as shipped: I need "mtime" support at many points, including
   import/commit, checkout, export, etc.

4. The collected commentary to date reveals (repeatedly) a
   watershed difference between "code" assets (e.g., source
   code to be used by Make or otherwise compiled into
   executable code) and "document" assets. SVN is used
   mostly by programmers managing source code, so it's
   natural to hear Erik say: "It [timestamp preservation]
   complicates the /CODE/ in your VC system." Many of the
   use cases referenced by users needing 'mtime control' involve
   the use of SVN for documents, where the files to be managed
   are often whole entities with independent status -- not
   code components to be compiled. Many applications which
   use these "document files" depend critically upon knowledge
   of the file mtime as a reasonable approximation for
   "last time of content modification." It's slightly
   disappointing that SVN "code" users who *don't* have this
   application need are skeptical about the legitimate
   use cases of "document" users.

5. If there's opportunity to contribute further to clarification
   of requirements and use cases -- in a design effort
   genuinely dedicated to solving this problem in the SVN space
   -- I am willing to help.

Robin Cover

[1] the issue is logged here:
http://subversion.tigris.org/issues/show_bug.cgi?id=1256

My posting of March 13, 2008:

http://svn.haxx.se/users/archive-2008-03/0462.shtml
also:
http://www.opensubscriber.com/message/users@subversion.tigris.org/8795331.html
http://readlist.com/lists/subversion.tigris.org/users/6/30057.html
http://www.nabble.com/Once-more:-Subversion-and-file-modification-time-(mtime)-td16022869.html

On Sat, Jun 7, 2008 at 2:53 AM, Erik Huelsmann <ehuels_at_gmail.com> wrote:
> On Sat, Jun 7, 2008 at 9:43 AM, Liviu <lab2k1_at_gmail.com> wrote:
>>
>> From: "Erik Huelsmann" Sent: Sat, June 07, 2008 2:25 AM
>>>
>>> On Sat, Jun 7, 2008 at 9:22 AM, Ryan Schmidt wrote:
>>>>
>>>> On Jun 7, 2008, at 00:22, Mark Reibert wrote:
>>>>
>>>>> Perhaps there is some other rationale for preserving timestamps with
>>>>> which I am not familiar.
>>>>
>>>> It is not for the version control system to decide what metadata
>>>> about my files is expendable.
>>>
>>> But a portable version control system may also not be in the position
>>> to version your meta data sanely between operating systems: [...]
>>
>> I'd think more OSs support file timestamps than symlinks.
>> It would be up to the particular client to know its platform, and act as
>> sanely as possible within its limitations.
>
> Right. But nobody was motivated to implement tracking of timestamps
> enough to implement it (whereas someone did for symlinks...). And in
> the current situation - where we intend to rewrite the working copy
> code - I suggest nobody starts that work within the current framework.
>
> In a previous mail you suggested there are no arguments *not* to
> include versioning of timestamps in your vc system (i believe), but I
> think there are plenty, which is exactly why it hasn't been done. It's
> a hairy topic:
>
> - Do you also commit a file if the timestamp changes? Some say 'of
> course', others say 'never'
>
> With which I mean: the feature isn't all that clearly defined and in
> fact may be a request for many different features (supporting many
> different use-cases).
>
> - It complicates the code in your VC system.
>
> Complexity is the enemy of stability. You should want the latter to be
> the top priority of your VC.
>
> - Time spent on developing this feature will reduce time spent on others
>
> I think Subversion has enough feature requests outstanding which are
> generally considered 'more important' than versioning of timestamps.
>
>
> Bye,
>
> Erik.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
>

-- 
Robin Cover
WWW: http://xml.coverpages.org
Tel: +1 (972) 296-1783
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org