You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2003/06/19 15:37:29 UTC
timestamp preservation design (issue 1256)
As a wise fictional character once said, it's not the answers that
hard, it's asking the right questions.
Let's begin by describing exactly what svn does/doesn't do right now:
* Entering the repository (import, add, commit):
We do nothing, no timestamp metadata is preserved. All files in
the changeset share a single "commit time" as metadata (the
revision's svn:date property.)
* Exiting the repository (checkout, export, update/switch):
Working-file timestamps are untouched, they reflect the moment
they were created or updated. Each file's "commit time" is
metadata in the .svn/entries file.
Furthermore, the working-file's timestamp is recorded in
.svn/entries, so that libsvn_wc can very quickly determine if the
file has been modified.
Ghudson has pointed out that two different designs have been bantered
around for making the svn client "set timestamps". Here they are.
1. The "Simple" Approach
* Entering the repository:
Still do nothing.
* Exiting the repository:
Working-file timestamps should be set to the "commit time" of
their last changed revision.
2. The "Complex" Approach (this seems to be what P.Marek has been
working on)
* Entering the repository:
Remember every timestamp, save it in the repository somehow.
* Exiting the repository:
Recover the original timestamp. The "commit time" only exists as
queryable metadata.
* Example:
foo.c, under version control, is locally modified at time X, so
the OS gives it timestamp X. It is then committed to the
repository. The repository remembers foo.c's timestamp X, even
though the revision's commit-time is X+1. Somebody checks out a
working copy and gets foo.c with timestamp X. Only by running
'svn info' (or other commands) can they see that it was last
changed in revision N, committed at time X+1.
These two behaviors seem mutually exclusive. That is, they can't
both be in effect at the same time.
*** Criticism against complex approach:
mbk points out that the complex proposal is inherently dangerous,
because of clock-skew problems between different client machines.
There's a very good maxim which says, "Only the server ever creates a
timestamp", which the simple proposal fulfills.
*** Criticism against the simple approach:
mbk points out this from the CVS manpage:
<mbk> -M[rev]
<mbk> Set the modification time on the new working file
<mbk> to be the date of the retrieved revision. Use this
<mbk> option with care; it can confuse make(1).
For example, if you backdate a working copy via 'svn up', a .c file
will have an older timestamp than it's .o, even though the .o *needs*
to be rebuilt. But 'make' won't do it. So how does the simple
behavior help build systems at all?
*** An open question to this list:
What exactly does CVS do, and how does it justify the behavior?
What do CVS users think of it?
For the record: I don't want to get into UI issues just yet. I
understand that whatever behaviors svn implements, we'll need a UI to
activate/deactivate it, either through props, or runtime config, a new
subcommand, or a 3rd party tool. But please, let's not discuss that
yet. First, I want to define the behavior we want, *then* I want to
discuss the UI.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by mark benedetto king <mb...@host-10_129_4_132.guardent.com>.
On Thu, Jun 19, 2003 at 09:18:47AM -0700, Jack Repenning wrote:
> At 10:37 AM -0500 6/19/03, Ben Collins-Sussman wrote:
> >mbk points out this from the CVS manpage:
> >
> ><mbk> -M[rev]
>
> Where do I find this option? My CVS man page (what I just rebuilt
> yesterday from 1.11p1, as a matter of fact) hasn't got this switch on
> any subcommand I can find.
>
This is actually from the RCS "co" manpage.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Jack Repenning <jr...@collab.net>.
At 10:37 AM -0500 6/19/03, Ben Collins-Sussman wrote:
>mbk points out this from the CVS manpage:
>
><mbk> -M[rev]
Where do I find this option? My CVS man page (what I just rebuilt
yesterday from 1.11p1, as a matter of fact) hasn't got this switch on
any subcommand I can find.
At 9:01 AM -0700 6/19/03, Michael Price wrote:
>mprice@paulsboro ~/local/tmp/test> cvs co test
Can you "co -M" in this wc?
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94015
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by "P.Marek" <pm...@users.sourceforge.net>.
> >After all this discussing I still believe that the stored properties
> > should be used *only* on export, so that build tools see which data has
> > changed.
>
> Did that truly mean "only export"? Or "export and checkout"? Just
> trying to clarify your intent, not expressing an opinion at this
> point.
Well, as already discussed, it would work for checkout *only* if it was a
clean checkout (ie an entire tree, not single files - else the relative times
are wrong wrt make), and a checkout on source files normally means that I'm
going to work on them - which changes the timestamps to values not in the
repository (at least with the next update, which I take as given uses current
time).
> Philipp, you're terrifying me. :-) Your proposal, so far, is to add
> at least three humongous new features:
>
> 1. so far, your patches have tried to create a new 'svn:' property
> for original timestamp preservation, so imports can remember the
> original unversioned mtime, rather than the commit-time. You've
> even proposed a whole new class of 'noneditable' properties
> living in the editable user space. (I think you started coding
> this before you realized we already non-editable 'entry' props
> living in .svn/entries... but still...)
>
> 2. You want a new property for binary-files that determines whether
> to use the commit-time or 'now' time.
>
> 3. Your solution requires property inheritance, which is another
> feature we don't have, and have discussed many times. (It's very
> *hard* to implement that, and it's been punted many times.)
To accomplish all goals and to give every user all that he wants takes some
coding :-)
But no. I don't suggest adding all these.
- AFAIK the entry-properties are living only in the wc and are not saved in
the repository.
- I'd have this property for all files - not just binary.
- and the property inheritance is something I believed was already working -
at least I remember reading something in the book. But possibly I'm wrong.
As I myself don't see an easy way to do this I'd leave it for now. Maybe it's
easier to use a wc-property which can be easily be set in all directories at
checkout time, and on subdirectory creating inheriting from the parent.
> At the moment, I still feel like the best solution is to mimic the CVS
> behavior:
>
> * it keeps developers and release-managers happy 90% of the time, and
> easily ignorable by people who don't care.
>
> * no surprises for former CVS users.
>
> * it only requires extremely trivial code changes; no new
> properties, no stored properties, no huge new features. Just a
> small tweak to libsvn_wc.
>
> In other words, it's a path of very low resistance, but still
> "scratches the itch" of timestamps pretty effectively.
>
> Phillip, can you talk about why you like/dislike the CVS behavior?
It's the problem of files ordering. I have to administer a whole lot of files,
which are a) binary b) not modifieable by me c) have to have their timestamps
correct as issued to me (because a timestamp-based copy (update only newer
files) is needed).
I don't like that CVS makes binary handling hard, that the files are
independent from each other, and that the timestamps are not saved.
I got attracted by svn because it handles binary files without the user, saved
*only* the binary changes (which makes a whole lotta difference if you've got
40 nearly identical versions of a 70MB binary file :-). Complete tree states
are saved (which I *really like*), commits are atomic (say goodbye, cvs ...)
and it promises that file meta-data is saved (I remember something about
possible acl, timestamps, access rights, ... save/restore support).
In short, everything that svn tries to do better than cvs.
As I learned that svn doesn't do timestamps (which I require), I set out to
implement them. I know that the decision is not easy - but I got some
responses telling me that mtime restoration is needed not only by me.
So I'm perfectly happy if the default behaviour is to mimic CVS; but I need
something to give consistent snapshots with at least mtimes to other people.
(At least for export - in my wc the meta-data is not as important)
So, seeing it one way, I read a promise from svn lips, which it doesn't hold
right now :-)
My question is now - if the current implemented behaviour - ie. restoration on
export, saving on import, add, commit, a "hidden" svn property - is given to
you as a patch, remarks included, no changes to the "update" functionality
(apart from hiding the property) -- are there any wishes, remarks, comments,
etc., or is there at least a 50:50 chance that someone looks at the patch?
Please, please! |-\
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Jack Repenning <jr...@collab.net>.
At 10:36 AM +0200 6/24/03, Ph. Marek wrote:
>After all this discussing I still believe that the stored properties should be
>used *only* on export, so that build tools see which data has changed.
Did that truly mean "only export"? Or "export and checkout"? Just
trying to clarify your intent, not expressing an opinion at this
point.
>or if it should be restored with the
>file(s) for easier version tracking by the user. (as it is common to say
>"this file is from march" instead of "I have version 515 of that file"
Ah, yes: *that's* the argument for repository times. Thanks for
stating it so clearly!
Still in all, I'm uncomfortable with all this. If it takes a bunch
of smart folks like this list so much debate merely to establish the
ideal mix of models and paradigms ("paradigmata"?), it seems like
most users will merely be confused--as, indeed, were we all for a
couple days' worth of discussion!
"Doing exactly what CVS does" has a certain usability charm, in that
CVS has trained a legion of users to its foibles. But this behavior
seems to flirt alarmingly with that nebulous line between "feature"
and "bug" that's Subversion's life-blood. Making it *more*
complicated (by providing a user-settable property) is certainly not
a clarification, whatever fancy tricks it enables.
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Ben Collins-Sussman <su...@collab.net>.
"Ph. Marek" <ph...@bmlv.gv.at> writes:
> But the use-case where non-source files are versioned (1), and these
> files are in a format which prohibits saving a version in them (2),
> leads me to think whether there should be a property (3) which says
> "on updating, if the file has no local modifications (ie, clean from
> the repository), use the mtime of this file's version; if it's
> modified, use the current time." [...]
>
> So the user can decide on a per-wc-base if it's source-files where the
> timestamp in needed in the tool-chain, or if it should be restored with the
> file(s) for easier version tracking by the user.
Philipp, you're terrifying me. :-) Your proposal, so far, is to add
at least three humongous new features:
1. so far, your patches have tried to create a new 'svn:' property
for original timestamp preservation, so imports can remember the
original unversioned mtime, rather than the commit-time. You've
even proposed a whole new class of 'noneditable' properties
living in the editable user space. (I think you started coding
this before you realized we already non-editable 'entry' props
living in .svn/entries... but still...)
2. You want a new property for binary-files that determines whether
to use the commit-time or 'now' time.
3. Your solution requires property inheritance, which is another
feature we don't have, and have discussed many times. (It's very
*hard* to implement that, and it's been punted many times.)
At the moment, I still feel like the best solution is to mimic the CVS
behavior:
* it keeps developers and release-managers happy 90% of the time, and
easily ignorable by people who don't care.
* no surprises for former CVS users.
* it only requires extremely trivial code changes; no new
properties, no stored properties, no huge new features. Just a
small tweak to libsvn_wc.
In other words, it's a path of very low resistance, but still
"scratches the itch" of timestamps pretty effectively.
Phillip, can you talk about why you like/dislike the CVS behavior?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
> > More precisely, if the file does not exist in the WC, it gets
> > last-commit-time, if it is patched, it gets current-time. This has
> > the advantage of playing nice with make(1). Any solution which
> > opens a hole for make figuring out whether a file has changed gets
> > scorn from me. -- justin
>
> What happens if I build at say rev X, update to rev A < X where a file
> does not exist, then update to rev B < X where that file does exist?
> If that file gets last-commit-time, make will not rebuild, even though
> it should, which will cause whoever implemented it that way to be
> tarred and feathered ;-)
After all this discussing I still believe that the stored properties should be
used *only* on export, so that build tools see which data has changed.
But the use-case where non-source files are versioned (1), and these files are
in a format which prohibits saving a version in them (2), leads me to think
whether there should be a property (3) which says "on updating, if the file
has no local modifications (ie, clean from the repository), use the mtime of
this file's version; if it's modified, use the current time."
So the user can decide on a per-wc-base if it's source-files where the
timestamp in needed in the tool-chain, or if it should be restored with the
file(s) for easier version tracking by the user. (as it is common to say
"this file is from march" instead of "I have version 515 of that file" - and
in svn many numbers will mean the same file, unlike cvs, which makes
comparing the files by revision nearly useless)
1) that is, there are no files depending on the versioned files, eg.
text-documents or spreadsheets
2) eg. binary files like pdf, MS-Word, ... I know that most file formats have
a version field nowadays, but patching this into a word document is a
liiittle bit beyond the things svn should do :-)
3) directory-property and inherited to the files, and/or for the subdirs,
overrideable per file
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Tue, Jun 24, 2003 at 05:26:39PM -0400, Greg Hudson wrote:
> On Tue, 2003-06-24 at 17:19, Jack Repenning wrote:
> > Not all implementations off make consider identical timestamps "up to date."
>
> Really? They must not like fast compilers.
Yeah, the native make has that feature in HP-UX up to at least 11.00.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-06-24 at 17:19, Jack Repenning wrote:
> Not all implementations off make consider identical timestamps "up to date."
Really? They must not like fast compilers.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Jack Repenning <jr...@collab.net>.
At 9:45 PM +0100 6/24/03, Max Bowsher wrote:
>The advantage this gives is: if a source and generated file are
>both updated, the generated file will be considered up-to-date by make,
>regardless of the order in which the individual files are updated.
Not all implementations off make consider identical timestamps "up to date."
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Max Bowsher <ma...@ukf.net>.
Ben Collins-Sussman wrote:
...
> Instead, it seems that CVS timestamps work correctly 90% of the time,
> for the two Really Big use-cases:
>
> * developers: 90% of the time they just keep updating to HEAD, and
> rebuilding. Thus updated files get 'now' time, and 'make' does
> what they want.
...
> So for these reasons, I think {Ben, Karl, Justin} are of the opinion
> that if we have a timestamp feature at all, the CVS behavior is
> probably the least evil of all options, and most useful.
Here is a way to improve on CVS behaviour with respect to generated files in
the repository:
During an update, set all timestamps to the time the update began (i.e.,
approximately 'now', and identical for each file touched by a single
update). The advantage this gives is: if a source and generated file are
both updated, the generated file will be considered up-to-date by make,
regardless of the order in which the individual files are updated.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Robert Pluim <rp...@bigfoot.com>.
Ben Collins-Sussman writes:
> I think I'm starting to agree with Justin, and Karl is too.
>
> I mean, at first, CVS's behavior sounds completely absurd. And yes,
> Robert points out that there *are* ways to confuse 'make' by updating
> to-and-fro in time, making files vanish and reappear. But then again,
> that's not a very common behavior either; 'make clean && make' will
> always rescue you from those situations.
If you notice them, yes. OTOH people toing-and-froing had better know
what they're doing (and if they don't, they _definitely_ need to run
make clean).
> Instead, it seems that CVS timestamps work correctly 90% of the time,
> for the two Really Big use-cases:
>
> * developers: 90% of the time they just keep updating to HEAD, and
> rebuilding. Thus updated files get 'now' time, and 'make' does
> what they want.
>
> * release managers: 90% of the time they do a fresh checkout (or
> export) of an entire tag. Commit-time timestamps provide them
> very easy, very useful metadata about their tree.
>
> So for these reasons, I think {Ben, Karl, Justin} are of the opinion
> that if we have a timestamp feature at all, the CVS behavior is
> probably the least evil of all options, and most useful.
+½ (we'll probably want some switches for the other 10%, though).
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by pl...@lanminds.com.
>>>>> On 24 Jun 2003, "Greg" == Greg Hudson wrote:
Greg> I'll be more explicit: the behavior may not be surprising to a
Greg> CVS user who knows what CVS does in this department (I assert
Greg> that such people are pretty rare); however, from experience
Greg> with CVS, I know that it's surprising behavior in general.
Greg> And, though our primary audience may be CVS users, that's no
Greg> excuse for writing in behavior which would be surprising to a
Greg> new user, just because CVS made the same mistake.
I'd like to point out that though your primary audience *was* CVS
users initially, those who seem to be attracted to SVN seem to not
necessarilly *be* former CVS users. IOW, those you *are* attracting
are not those you initially *set out* to attract (though there are a
fair number of them here as well!).
Therefore, though the behavior may not be surprising to some one well
versed in the dustier corners of CVS behavior, if it is at all
surprising or non-intuitive behavior for someone completely new to
revision control, I think it should be avoided, or fixed to exhibit
the expected/intuitive behavior. (does that make sense?)
(going back to sleep now :)
--
Seeya,
Paul
--
Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-06-24 at 13:45, Ben Collins-Sussman wrote:
> It helps for the same reason that it's useful in an export. Somebody
> checks out a fresh tree... it's interesting for the timestamps to
> intially show how "old" each file is.
>
> I'm not sure how to debate this point: is there an 'objective' way to
> prove that a fresh checkout [is|isn't] surprising if it has
> [commit-time|now-time] timestamps?
The problem is that a checked-out directory will, more likely than not,
be updated. And if you show the commit times after a checkout, then
people (at least, the people who notice at all) will expect you to show
the commit times after an update, too. But we can't do that by default,
because that would break "make" even in the common cases.
Suppose there were some reason we couldn't implement the svn:executable
property at update time, but we could at checkout time. Would it make
sense to implement it anyway? No; it would be confusing and would only
hurt people.
On the other hand, an exported directory is never updated. So showing
the commit times in an exported directory does not create any bogus
expectations.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
>
> > * checkouts and updates always use the commit-time
> >
> > * updates always use the 'now' time.
> >
> > This allows 'make' to work no matter what, even if you do unusual wc
> > backdating that involves deletes & adds. Is that a 100% solution?
>
> I think you meant to say "checkouts and exports."
Yes, sorry, dumb typo.
> I think that solution is 100% make-compliant, but I don't see how
> changing the checkout behavior helps anyone.
It helps for the same reason that it's useful in an export. Somebody
checks out a fresh tree... it's interesting for the timestamps to
intially show how "old" each file is.
I'm not sure how to debate this point: is there an 'objective' way to
prove that a fresh checkout [is|isn't] surprising if it has
[commit-time|now-time] timestamps?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-06-24 at 13:13, Ben Collins-Sussman wrote:
> > It was highly surprising to me when I found out about it as a CVS user.
>
> Heh, that's funny. So I'm saying that "but CVS users are used to it",
> and you're saying "but that doesn't mean it isn't weird". :-)
Perhaps I was talking past you, sorry. I'll be more explicit: the
behavior may not be surprising to a CVS user who knows what CVS does in
this department (I assert that such people are pretty rare); however,
from experience with CVS, I know that it's surprising behavior in
general.
And, though our primary audience may be CVS users, that's no excuse for
writing in behavior which would be surprising to a new user, just
because CVS made the same mistake.
> * checkouts and updates always use the commit-time
>
> * updates always use the 'now' time.
>
> This allows 'make' to work no matter what, even if you do unusual wc
> backdating that involves deletes & adds. Is that a 100% solution?
I think you meant to say "checkouts and exports." I think that solution
is 100% make-compliant, but I don't see how changing the checkout
behavior helps anyone.
> Yeah, I'm on crack, never mind. I was thinking about "release
> managers who create tarballs via 'svn export'".
If this is the only audience your proposal can satisfy, then only the
"export" command should be modified. I'm okay with changing that.
(Especially because we have this nice, separate export editor now.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Ben Collins-Sussman wrote:
> OK, well, let's try a small variation (from kfogel). What if our
> behavior were this:
>
> * checkouts and updates always use the commit-time
>
> * updates always use the 'now' time.
Umh, how can updates both "always use the commit-time" and "always use
the 'now' time"?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> On Tue, 2003-06-24 at 12:52, Ben Collins-Sussman wrote:
> > Greg Hudson <gh...@MIT.EDU> writes:
> >
> > > On Tue, 2003-06-24 at 10:46, Ben Collins-Sussman wrote:
> > > > I think I'm starting to agree with Justin, and Karl is too.
> > >
> > > Ew, no, no, no, no, no. -1 on the CVS behavior.
> > >
> > > It's surprising,
> >
> > To whom?
>
> It was highly surprising to me when I found out about it as a CVS user.
Heh, that's funny. So I'm saying that "but CVS users are used to it",
and you're saying "but that doesn't mean it isn't weird". :-)
> > For developers, it *does* satisfy make 90% of the time.
>
> If you're going to do something truly awful in order to make something
> else work, it should be a 100% solution, not a 90% solution.
OK, well, let's try a small variation (from kfogel). What if our
behavior were this:
* checkouts and updates always use the commit-time
* updates always use the 'now' time.
This allows 'make' to work no matter what, even if you do unusual wc
backdating that involves deletes & adds. Is that a 100% solution?
If so, it would also make my hypothetical release managers happy as
well. And it would be just as trivial a libsvn_wc change.
> > Maybe I should say: "managers". Managers check out whole tags. They
> > don't keep working-copies lying around. They check out a tree, build
> > it, then delete the tree. Same goes for automated build-systems.
>
> I'm a release manager (in my work capacity). It takes hours to check
> out my 1.6GB source tree. I keep one lying around, and so does my
> automated build system.
Yeah, I'm on crack, never mind. I was thinking about "release
managers who create tarballs via 'svn export'".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by John Peacock <jp...@rowman.com>.
Philip Martin wrote:
> In essence I would like the timestamp behaviour to mean that the
> timestamps in a working copy do not depend on how the working copy was
> obtained, whether by checkout, update or modify-commit the timestamps
> are the same.
A little light just went on in my head on the subtleties with the interaction
between versioned source files and derived files. I'm still more interested in
not losing the timestamp information, but I can now see how it likely to be very
difficult to get it 100% right.
<Anyone who has already made this conceptual leap should just hit delete>
Say I am working on a project with 1 other person on a project. I commit a
change to a file and then 30 minutes later (after having made some other changed
and committing again), I run make (possibly again). My directory now looks like
this:
-rw-r--r-- 1 jpeacock jpeacock 6615 Jun 22 11:23 util.c
-rw-r--r-- 1 jpeacock jpeacock 7304 Jun 22 11:54 util.o
But, unbeknownst to me, my partner also changed that file around that time, so
his directory looks like this:
-rw-r--r-- 1 otherusr otherusr 6625 Jun 22 11:43 util.c
-rw-r--r-- 1 otherusr otherusr 7324 Jun 22 11:44 util.o
Then I `svn up` and my directory looks like this
-rw-r--r-- 1 jpeacock jpeacock 6625 Jun 22 11:43 util.c
-rw-r--r-- 1 jpeacock jpeacock 7304 Jun 22 11:54 util.o
Note that the source file is newer, but not newer than the compiled version, so
the makefile will not rebuild it.
Yes, the correct order should be `svn up; make` or `make realclean; make` but
for really large projects, the second is a real pain, and for small changes, the
first is annoying (since it might result in a conflict).
I don't know the right answer; I just wanted to document that I understand the
question better now and maybe give someone else a better idea...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> Philip Martin <ph...@codematters.co.uk> writes:
>
>> > If you're going to do something truly awful in order to make something
>> > else work, it should be a 100% solution, not a 90% solution.
>>
>> I tend to agree with Greg here, I don't really like the CVS behaviour
>> (but then I'm not a CVS user). If we are going to go to all the
>> trouble of storing and retrieving commit times it seems odd to do it
>> only for CVS compatibility.
>
> None of my proposals have been about storing any new information. I
> don't want to implement any new systems to save/restore timestamps.
>
> We already have commit-times coming back from the server, and embedded
> in entries files. My proposals have simply been a matter of "hey, why
> not use them once in a while, for something other than keyword
> expansion." Very, very simple.
Commit times are OK (ClearCase uses commit times) but it does make my
full timestamp behaviour a little more complicated.
In essence I would like the timestamp behaviour to mean that the
timestamps in a working copy do not depend on how the working copy was
obtained, whether by checkout, update or modify-commit the timestamps
are the same. If commit times are used it means that the commit
process needs to update the timestamps on the committed files.
(ClearCase uses commit time and commit does change the timestamp on
committed files. Hmm, I guess that means I'm arguing for "ClearCase
emulation" rather than "CVS emulation". Since I don't intend to
implement it I think I'll just shut up!)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Ben Collins-Sussman <su...@collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:
> > If you're going to do something truly awful in order to make something
> > else work, it should be a 100% solution, not a 90% solution.
>
> I tend to agree with Greg here, I don't really like the CVS behaviour
> (but then I'm not a CVS user). If we are going to go to all the
> trouble of storing and retrieving commit times it seems odd to do it
> only for CVS compatibility.
None of my proposals have been about storing any new information. I
don't want to implement any new systems to save/restore timestamps.
We already have commit-times coming back from the server, and embedded
in entries files. My proposals have simply been a matter of "hey, why
not use them once in a while, for something other than keyword
expansion." Very, very simple.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Philip Martin <ph...@codematters.co.uk>.
Greg Hudson <gh...@MIT.EDU> writes:
>> > Ew, no, no, no, no, no. -1 on the CVS behavior.
>> >
>> > It's surprising,
>>
>> To whom?
>
> It was highly surprising to me when I found out about it as a CVS user.
>
>> > it has no interesting properties (it doesn't satisfy make, and a
>> > directory which has been updated even once has a mismash of checkout
>> > dates and current dates),
>>
>> For developers, it *does* satisfy make 90% of the time.
>
> If you're going to do something truly awful in order to make something
> else work, it should be a 100% solution, not a 90% solution.
I tend to agree with Greg here, I don't really like the CVS behaviour
(but then I'm not a CVS user). If we are going to go to all the
trouble of storing and retrieving commit times it seems odd to do it
only for CVS compatibility.
Assuming someone gets as far as implementing a system to save/restore
timestamps, then I'd much rather see a config/option setting that
controls the behaviour. I'd like to be able to select the current
behaviour, and I also like to be able to select full timestamps. Full
timestamp behaviour would set the timestamps to the stored timestamps
for checkout, update, revert, export, URL->wc copy (WC->WC copy as
well?) and merge, with the proviso that an update that modifies a
file with local modifications, and a merge that modifies existing
files, should use now rather than the stored timestamp.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-06-24 at 12:52, Ben Collins-Sussman wrote:
> Greg Hudson <gh...@MIT.EDU> writes:
>
> > On Tue, 2003-06-24 at 10:46, Ben Collins-Sussman wrote:
> > > I think I'm starting to agree with Justin, and Karl is too.
> >
> > Ew, no, no, no, no, no. -1 on the CVS behavior.
> >
> > It's surprising,
>
> To whom?
It was highly surprising to me when I found out about it as a CVS user.
> > it has no interesting properties (it doesn't satisfy make, and a
> > directory which has been updated even once has a mismash of checkout
> > dates and current dates),
>
> For developers, it *does* satisfy make 90% of the time.
If you're going to do something truly awful in order to make something
else work, it should be a 100% solution, not a 90% solution.
> > > * release managers: 90% of the time they do a fresh checkout (or
> > > export) of an entire tag.
> >
> > For a small tree, maybe. For a big tree, why would I waste my time on a
> > fresh checkout when I could do an update or switch?
>
> Maybe I should say: "managers". Managers check out whole tags. They
> don't keep working-copies lying around. They check out a tree, build
> it, then delete the tree. Same goes for automated build-systems.
I'm a release manager (in my work capacity). It takes hours to check
out my 1.6GB source tree. I keep one lying around, and so does my
automated build system.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Colin Watson <cj...@flatline.org.uk>.
On Wed, Jun 25, 2003 at 12:15:19PM +0100, Max Bowsher wrote:
> Branden Robinson wrote:
> > Use case:
> >
> > A lot of Debian package maintainers are going to do 'svn export;
> > debuild', and 99+% of the time, debuild is going to invoke "make".
> >
> > It's not practical to build Debian packages within CVS or SVN checkouts,
> > because the former is littered with CVS/ directories and the latter with
> > .svn/ directories.
>
> I don't know anything about Debian packages, but...
>
> Why not make the build tools ignore these, as, for example, Perl's
> MakeMaker does?
Ironically, building Debian packages of Perl modules from Subversion
checkouts is currently a particular headache requiring runes to be
inserted in Makefile.PL, since MakeMaker in Perl 5.8.0 does *not*
exclude .svn directories ...
http://bugs.debian.org/190065
--
Colin Watson [cjwatson@flatline.org.uk]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Max Bowsher <ma...@ukf.net>.
Branden Robinson wrote:
> On Tue, Jun 24, 2003 at 11:52:26AM -0500, Ben Collins-Sussman wrote:
>> For developers, it *does* satisfy make 90% of the time. Most
>> developers run 'svn up; make'. Is it the various broken-backdating
>> scenarios that bother you? That 10%?
>
> Use case:
>
> A lot of Debian package maintainers are going to do 'svn export;
> debuild', and 99+% of the time, debuild is going to invoke "make".
>
> It's not practical to build Debian packages within CVS or SVN checkouts,
> because the former is littered with CVS/ directories and the latter with
> .svn/ directories.
I don't know anything about Debian packages, but...
Why not make the build tools ignore these, as, for example, Perl's MakeMaker
does?
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Colin Watson <cj...@flatline.org.uk>.
On Wed, Jun 25, 2003 at 03:37:16AM -0500, Branden Robinson wrote:
> It's not practical to build Debian packages within CVS or SVN checkouts,
> because the former is littered with CVS/ directories and the latter with
> .svn/ directories.
Hm. I build Debian packages within checkouts all the time, although it
does occasionally require hacks like 'DH_ALWAYS_EXCLUDE=CVS:.svn' about
which I have to be a little careful. I can appreciate that some people
might prefer to export.
--
Colin Watson [cjwatson@flatline.org.uk]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Branden Robinson <br...@deadbeast.net>.
On Tue, Jun 24, 2003 at 11:52:26AM -0500, Ben Collins-Sussman wrote:
> For developers, it *does* satisfy make 90% of the time. Most
> developers run 'svn up; make'. Is it the various broken-backdating
> scenarios that bother you? That 10%?
Use case:
A lot of Debian package maintainers are going to do 'svn export;
debuild', and 99+% of the time, debuild is going to invoke "make".
It's not practical to build Debian packages within CVS or SVN checkouts,
because the former is littered with CVS/ directories and the latter with
.svn/ directories.
--
G. Branden Robinson | We either learn from history or,
Free Software Developer | uh, well, something bad will
branden@deadbeast.net | happen.
http://deadbeast.net/~branden/ | -- Bob Church
Re: timestamp preservation design (issue 1256)
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> On Tue, 2003-06-24 at 10:46, Ben Collins-Sussman wrote:
> > I think I'm starting to agree with Justin, and Karl is too.
>
> Ew, no, no, no, no, no. -1 on the CVS behavior.
>
> It's surprising,
To whom? Our target audience is mainly CVS users, and you've already
heard testimony from two lurkers how surprised they were that 'svn co'
all had uniform 'now' timestamps.
> it has no interesting properties (it doesn't satisfy make, and a
> directory which has been updated even once has a mismash of checkout
> dates and current dates),
For developers, it *does* satisfy make 90% of the time. Most
developers run 'svn up; make'. Is it the various broken-backdating
scenarios that bother you? That 10%?
> and it's ugly.
No argument there. But no uglier than other proposals I've seen. A
lot simpler, really. But this whole topic gives me the willies. :-)
> > * release managers: 90% of the time they do a fresh checkout (or
> > export) of an entire tag.
>
> For a small tree, maybe. For a big tree, why would I waste my time on a
> fresh checkout when I could do an update or switch?
Maybe I should say: "managers". Managers check out whole tags. They
don't keep working-copies lying around. They check out a tree, build
it, then delete the tree. Same goes for automated build-systems.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-06-24 at 10:46, Ben Collins-Sussman wrote:
> I think I'm starting to agree with Justin, and Karl is too.
Ew, no, no, no, no, no. -1 on the CVS behavior.
It's surprising, it has no interesting properties (it doesn't satisfy
make, and a directory which has been updated even once has a mismash of
checkout dates and current dates), and it's ugly.
> * release managers: 90% of the time they do a fresh checkout (or
> export) of an entire tag.
For a small tree, maybe. For a big tree, why would I waste my time on a
fresh checkout when I could do an update or switch?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Ben Collins-Sussman <su...@collab.net>.
"Sander Striker" <st...@apache.org> writes:
> > From: sussman@collab.net [mailto:sussman@collab.net]
> > Sent: Tuesday, June 24, 2003 4:47 PM
>
> > Instead, it seems that CVS timestamps work correctly 90% of the time,
> > for the two Really Big use-cases:
> >
> > * developers: 90% of the time they just keep updating to HEAD, and
> > rebuilding. Thus updated files get 'now' time, and 'make' does
> > what they want.
> >
> > * release managers: 90% of the time they do a fresh checkout (or
> > export) of an entire tag. Commit-time timestamps provide them
> > very easy, very useful metadata about their tree.
>
> Not to be a pain, but isn't checkout just update? Do you want to
> split the functionality again?
If you want to discuss implementation detail:
We have a single wc editor for checkouts and updates. It "knows"
whether it's doing a checkout or update. Your statement that
"checkout == update" is only true from the *RA* layer's point of view,
not libsvn_wc.
So the way we'd implement this is: update_editor.c:add_file() would
install a commit-time timestamp, while open_file() would install a
'now' timestamp. (In checkouts, add_file() is the only function ever
called. For updates, we'd most get open_file() calls, but the
occasional add_file() call would still get a commit-time timestamp,
which is fine.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: timestamp preservation design (issue 1256)
Posted by Jack Repenning <jr...@collab.net>.
At 7:29 PM +0200 6/24/03, Robert Pluim wrote:
>Jack Repenning writes:
> > And, for the coup de grace: isn't "export," likewise, "update" with
> > window-dressing?
>
>So you don't want time-stamp preservation on export either?
My anguish wasn't about what I wanted, only about what seemed
possible (given Sander's comment that "checkout is update"). But
since Ben says they're not the same at the point that matters,
there's no problem here. (Ben says, in fact, that export is even more
not-update than checkout is, how cool is that?).
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: timestamp preservation design (issue 1256)
Posted by Robert Pluim <rp...@bigfoot.com>.
Jack Repenning writes:
> At 6:53 PM +0200 6/24/03, Sander Striker wrote:
> >Not to be a pain, but isn't checkout just update? Do you want to
> >split the functionality again?
>
> Aaaahhhh! The stake right through the heart!
>
> And, for the coup de grace: isn't "export," likewise, "update" with
> window-dressing?
So you don't want time-stamp preservation on export either? I
personally don't care, but I can quite easily see that some people
might, especially if they're checking generated sources into their
repository. [1]
Robert
Footnotes:
[1] We can have a discussion on the relative evilness of that some
other time ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: timestamp preservation design (issue 1256)
Posted by Jack Repenning <jr...@collab.net>.
At 6:53 PM +0200 6/24/03, Sander Striker wrote:
>Not to be a pain, but isn't checkout just update? Do you want to
>split the functionality again?
Aaaahhhh! The stake right through the heart!
And, for the coup de grace: isn't "export," likewise, "update" with
window-dressing?
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by John Peacock <jp...@rowman.com>.
Mark Watts wrote:
> Like John, I have been trying to follow this discussion and find that I
> agree with him about being least surprised by a versioned commit time for
> each file.
But to just disagree with myself a little, I could _live_ without versioned
commit times. I guess my point was if something *had* to be done, that way
would get my vote (for whatever that's worth ;~).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: timestamp preservation design (issue 1256)
Posted by Mark Watts <mw...@stny.rr.com>.
> -----Original Message-----
> From: John Peacock [mailto:jpeacock@rowman.com]
> Sent: Tuesday, June 24, 2003 14:05
> To: kfogel@collab.net
> Cc: Sander Striker; sussman@collab.net; SVN Dev List
>
> kfogel@collab.net wrote:
> > Ben Collins-Sussman writes:
> >
> >>So for these reasons, I think {Ben, Karl, Justin} are of
> the opinion
> >>that if we have a timestamp feature at all, the CVS behavior is
> >>probably the least evil of all options, and most useful.
> >
> >
> > Yah. Plus the no-surprises factor if we just do what CVS does.
>
> I've been following this discussion and trying to put into
> words what my expectations would be. The method that would
> suprise _me_ the least is if I commit a project, then check
> it back out in a different location and all the of timestamps
> matched (except possibly directories). And that would be
> true for any historical version, so I could recreate a given
> project at any point, exactly as if I had tar'd it up. And
> yes, I do realize that means a versioned commit time for each file.
Like John, I have been trying to follow this discussion and find that I
agree with him about being least surprised by a versioned commit time for
each file.
The first time I did a fresh checkout from Subversion I was VERY surprised
about the date time stamps of the files. After reading all the
documentation about how the entire directories were versioned and to revert
to a particular revision of the entire directory tree was so easy, I guess I
assummed (yes a bad idea I know) that when I checked out a particular
revision I would get a tree that looked 'exactly' like it did at commit
time. When that wasn't the case, as I said I was very surprised.
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by John Peacock <jp...@rowman.com>.
kfogel@collab.net wrote:
> Ben Collins-Sussman writes:
>
>>So for these reasons, I think {Ben, Karl, Justin} are of the opinion
>>that if we have a timestamp feature at all, the CVS behavior is
>>probably the least evil of all options, and most useful.
>
>
> Yah. Plus the no-surprises factor if we just do what CVS does.
I've been following this discussion and trying to put into words what my
expectations would be. The method that would suprise _me_ the least is if I
commit a project, then check it back out in a different location and all the of
timestamps matched (except possibly directories). And that would be true for
any historical version, so I could recreate a given project at any point,
exactly as if I had tar'd it up. And yes, I do realize that means a versioned
commit time for each file.
If there was a way to override that for generated files (since that came up) to
have their time be different (to force their regeneration), that would be nice,
but hardly essential. Say, an attribute that this file should be forced to be
just a little older than some other specified file.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by kf...@collab.net.
Ben Collins-Sussman writes:
> So for these reasons, I think {Ben, Karl, Justin} are of the opinion
> that if we have a timestamp feature at all, the CVS behavior is
> probably the least evil of all options, and most useful.
Yah. Plus the no-surprises factor if we just do what CVS does.
"Sander Striker" <st...@apache.org> writes:
> > * release managers: 90% of the time they do a fresh checkout (or
> > export) of an entire tag. Commit-time timestamps provide them
> > very easy, very useful metadata about their tree.
>
> Not to be a pain, but isn't checkout just update? Do you want to
> split the functionality again?
What Ben means is that the delta editor's add_foo() functions will use
the commit-time, but open_foo() will use now-time. Since checkouts
"just happen" to use only add_foo(), everything works out dandily.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: timestamp preservation design (issue 1256)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, June 24, 2003 6:53 PM +0200 Sander Striker <st...@apache.org>
wrote:
> Not to be a pain, but isn't checkout just update? Do you want to
> split the functionality again?
That's why I recommended it possibly be based on whether the file previously
existed in the WC or not. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: timestamp preservation design (issue 1256)
Posted by Sander Striker <st...@apache.org>.
> From: sussman@collab.net [mailto:sussman@collab.net]
> Sent: Tuesday, June 24, 2003 4:47 PM
> Instead, it seems that CVS timestamps work correctly 90% of the time,
> for the two Really Big use-cases:
>
> * developers: 90% of the time they just keep updating to HEAD, and
> rebuilding. Thus updated files get 'now' time, and 'make' does
> what they want.
>
> * release managers: 90% of the time they do a fresh checkout (or
> export) of an entire tag. Commit-time timestamps provide them
> very easy, very useful metadata about their tree.
Not to be a pain, but isn't checkout just update? Do you want to
split the functionality again?
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Ben Collins-Sussman <su...@collab.net>.
Robert Pluim <rp...@bigfoot.com> writes:
> Justin Erenkrantz writes:
> >
> > More precisely, if the file does not exist in the WC, it gets
> > last-commit-time, if it is patched, it gets current-time. This has
> > the advantage of playing nice with make(1). Any solution which
> > opens a hole for make figuring out whether a file has changed gets
> > scorn from me. -- justin
>
> What happens if I build at say rev X, update to rev A < X where a file
> does not exist, then update to rev B < X where that file does exist?
> If that file gets last-commit-time, make will not rebuild, even though
> it should, which will cause whoever implemented it that way to be
> tarred and feathered ;-)
I think I'm starting to agree with Justin, and Karl is too.
I mean, at first, CVS's behavior sounds completely absurd. And yes,
Robert points out that there *are* ways to confuse 'make' by updating
to-and-fro in time, making files vanish and reappear. But then again,
that's not a very common behavior either; 'make clean && make' will
always rescue you from those situations.
Instead, it seems that CVS timestamps work correctly 90% of the time,
for the two Really Big use-cases:
* developers: 90% of the time they just keep updating to HEAD, and
rebuilding. Thus updated files get 'now' time, and 'make' does
what they want.
* release managers: 90% of the time they do a fresh checkout (or
export) of an entire tag. Commit-time timestamps provide them
very easy, very useful metadata about their tree.
So for these reasons, I think {Ben, Karl, Justin} are of the opinion
that if we have a timestamp feature at all, the CVS behavior is
probably the least evil of all options, and most useful.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Robert Pluim <rp...@bigfoot.com>.
Justin Erenkrantz writes:
>
> More precisely, if the file does not exist in the WC, it gets
> last-commit-time, if it is patched, it gets current-time. This has
> the advantage of playing nice with make(1). Any solution which
> opens a hole for make figuring out whether a file has changed gets
> scorn from me. -- justin
What happens if I build at say rev X, update to rev A < X where a file
does not exist, then update to rev B < X where that file does exist?
If that file gets last-commit-time, make will not rebuild, even though
it should, which will cause whoever implemented it that way to be
tarred and feathered ;-)
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, June 20, 2003 9:33 AM -0700 Jack Repenning
<jr...@collab.net> wrote:
> Put another way: if you want vintages, use checkout. You're probably doing
> something like backup or export/import or audit or something else
> administrative, not developing, anyway. If you want to develop, then you
> desperately want your builds to do the right thing, and you can afford to
> sacrifice the "vintage" semantic to get that.
If we're going to do something re: timestamps, this would be the approach I'd
take. export and checkout get commit-time, and update gets current-time.
More precisely, if the file does not exist in the WC, it gets
last-commit-time, if it is patched, it gets current-time. This has the
advantage of playing nice with make(1). Any solution which opens a hole for
make figuring out whether a file has changed gets scorn from me. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Jack Repenning <jr...@collab.net>.
At 5:38 PM +0200 6/20/03, Olaf Hering wrote:
> > For example, if you backdate a working copy via 'svn up', a .c file
>> will have an older timestamp than it's .o, even though the .o *needs*
>> to be rebuilt. But 'make' won't do it. So how does the simple
>> behavior help build systems at all?
>
>up should touch the file with the current time, co and export should
>preserve the commit time. That is what cvs does, at least.
I think Olaf has finally enabled me to understand why CVS does it
this way. It's an optimization thing:
* checkout provides commit timestamps (the vintage of the file
itself), because that's sometimes useful, and it's reasonably
build-safe (you're starting from a blank slate).
* update, on the other hand, provides as-loaded timestamps, in order
to ensure builds do the right thing. This sacrifices the "file
vintage" information to the higher good of correct builds.
Put another way: if you want vintages, use checkout. You're probably
doing something like backup or export/import or audit or something
else administrative, not developing, anyway. If you want to develop,
then you desperately want your builds to do the right thing, and you
can afford to sacrifice the "vintage" semantic to get that.
I'm not sure I *like* this: seems too complicated, obscure, and
undocumented (/me checks his cedarqvist just to be sure--yeah, no
reference to that here!). But at least, now I *understand* it.
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94015
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Olaf Hering <ol...@suse.de>.
> For example, if you backdate a working copy via 'svn up', a .c file
> will have an older timestamp than it's .o, even though the .o *needs*
> to be rebuilt. But 'make' won't do it. So how does the simple
> behavior help build systems at all?
up should touch the file with the current time, co and export should
preserve the commit time. That is what cvs does, at least.
Gruss Olaf
--
USB is for mice, FireWire is for men!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Jack Repenning <jr...@collab.net>.
At 12:53 PM -0400 6/19/03, Greg Hudson wrote:
>I think the simple approach has limited value, because the commit times
>of a big collection of imported files are unlikely to have any useful
>relationship.
Well, what is their relationship, and whether that's useful, depends
on a lot of assumptions about the surrounding process. It's not
useful for "the ghudson use case," but some people really get
addicted to its peculiarities.
>I think the complex approach has value, because then you can:
Yes, I agree that this is an interesting use case.
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94015
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Greg Hudson <gh...@MIT.EDU>.
To summarize Ben's mail, we have three options presented:
* Status quo: record only commit time; never set timestamps in wc
* Simple approach: record only commit time; set timestamp to commit
time in wc if asked
* Complex approach: record mod time of file when committing; set
timestamp to commit time or to recorded mod time if asked
I think the status quo has the important feature of being trivial to
implement. We are talking about libsvn_wc here, the library we're not
supposed to complicated before a post-1.0 redesign.
I think the simple approach has limited value, because the commit times
of a big collection of imported files are unlikely to have any useful
relationship.
I think the complex approach has value, because then you can:
* Import code, including generated files
* Make local mods and check them in
* Check out the result, with --timestamps orig, or whatever
* Build the result (or a copy of the result) without trying to
recreate generated files
without requiring the code's build system to properly respect
"maintainer mode" vs. "non-maintainer-mode". However, it does require
modifying the entries file to remember the --timestamps option, and it
most likely requires timestamp handling sprinkled all over libsvn_wc
given how libsvn_wc is currently designed. So I'm not convinced that it
should be allowed as a 1.0 feature.
(I understand the make(1) risks of the simple approach and the client
clock synchronization risks of the complex approach. Because of those
risks, the status quo should be the default behavior.)
On Thu, 2003-06-19 at 11:37, Ben Collins-Sussman wrote:
> What exactly does CVS do, and how does it justify the behavior?
> What do CVS users think of it?
On the way in, CVS records only the commit time. The "-d" option to cvs
import will use the mod time of the imported files as the commit time,
which of course causes your repository's commit times to be a lie. (To
work around this problem, I have a perl script which "squeezes" the
timestamps of a directory so that they're all close to the current time,
but have the same relationships.)
On the way out, CVS sets mod times to the commit time when a wc file is
first created. However, when a file is updated, CVS leaves the mod time
at the current time. I have no idea what mbk's -M option is; like Jack
Repenning, I can't find it in my version of CVS.
So, if you import with the -d option and then make local mods, a
checkout will bear the same timestamp relationships, allowing you to do
the same thing as I said above. However, if you then "cvs update" the
working directory, you won't get useful timestamp relationships. So
you'd have to do a checkout from scratch each time.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Jack Repenning <jr...@collab.net>.
At 10:37 AM -0500 6/19/03, Ben Collins-Sussman wrote:
>*** Criticism against complex approach:
>
>mbk points out that the complex proposal is inherently dangerous,
>because of clock-skew problems between different client machines.
Clock skew is a problem for either approach, because it redefines
what a time actually means. The complex approach provides more
points of confusion, but not really any more failure modes: the
solution must be to keep all systems in sync, either way you slice it.
On the other hand, clock skew is *not* a problem for either approach,
because anyone asking for timestamp preservation already understands
this, and has heard of NTP.
>*** Criticism against the simple approach:
>
><mbk> it can confuse make(1).
Yes it can. This is a problem for either approach. In fact, so can
non-preservation of timestamps, though not in so many ways, and most
of them are in the "safe" direction. (The worst make problems for
non-preservation arise from the fact that the new files get
timestamped in the order they're pulled, not necessarily in the order
they're processed by make; if you version output files, they can look
like they need to be rebuilt when this is not so. You will say to me
"don't do that," but you have perhaps never worked in a system that
took hours to generate certain output files, and days to build the
entire system; it changes your perspective on these things a mite.)
make-confusion is childishly easy, a swell game any number can play,
like tormenting the cat.
OTOH, make confusion is not a problem for any of the three
approaches: the make panacea is "make clean," and the rich taxonomy
of clean-like targets in most makefiles testifies that people can
learn to live with these limits.
So, if we stipulate that any use of timestamp preservation:
- requires clock syncing, and
- requires some thought about the new disciplines of "make clean"
... then I think we've quite levelled this playing field.
What's left to explore is the use cases that create the request in
the first place (the question that comes before every question).
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94015
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by David Mankin <ma...@ants.com>.
On Thursday, June 19, 2003, at 08:37 AM, Ben Collins-Sussman wrote:
> Let's begin by describing exactly what svn does/doesn't do right now:
>
> * Entering the repository (import, add, commit):
>
> We do nothing, no timestamp metadata is preserved. All files in
> the changeset share a single "commit time" as metadata (the
> revision's svn:date property.)
>
> * Exiting the repository (checkout, export, update/switch):
>
> Working-file timestamps are untouched, they reflect the moment
> they were created or updated. Each file's "commit time" is
> metadata in the .svn/entries file.
(First I present motivating use-cases, then Two principles to which
they lead.)
I'm going to have to argue against the status quo approach here, at
least for "simple" users. All of the discussion of what's right for a
build system only takes into account the times when Subversion is used
as a *source code* versioning system. We've seen many use cases
discussed on the mailing list of people who are (going to be) using svn
for things that aren't source code. People who are not dealing with
build systems don't care that the timestamps of a recently svn-updated
or checked-out Word document should be newer than a locally modified
PowerPoint. Instead, they want to know (by looking at the filesystem)
how old the Word document is. With the status quo, a new checkout has
all the files dated Today, and none dated February, no matter how old
they are. Without timestamp preservation, svn may be able to replace
CVS, but it won't be able to replace the dreaded shared folder on a
file server for these users.
Also, when a file is copied out of a working copy, modification date is
the only versioning metadata that is kept with it. (Non source-code
files often aren't text format and so can't be labeled with a $Version$
tag.) If I copy a gif file from my computer to the web server, I only
have timestamp to tell me which version is deployed. If someone else's
working copy has different timestamps for the same version of the
image, they will think it's not the same version of the file. The same
problem will happen if I re-checkout and the timestamps change. This
can lead to unnecessary file uploads (especially if my ftp client is
timestamp sensitive, but isn't rsync), which leads to unnecessary
timestamp changes on the server, which leads to images being
re-downloaded by all clients. Yuck.
Two principles. If I choose the "timestamp preserving" option for my
working copy:
1) Timestamp handling should be easy to explain: The timestamp of a
file should always approximate the date it was last modified. (I don't
care much whether it's the date it was actually last touched, or the
date it was committed -- assuming that for the most common use cases
the two will be similar.)
2) Checkouts and updates should be interchangeable. (If I have no local
mods, why should I have different semantics (timestamps) if I throw
away my working copy and checkout again.) This implies not setting the
timestamp to something different based on the subcommand (co, up,
export) used.
I'm not saying that timestamp preservation is right for everyone, but
it certainly should be an option for those for whom it is. [UI
discussion postponed.]
-David Mankin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: timestamp preservation design (issue 1256)
Posted by Michael Price <mi...@computer.org>.
--- Ben Collins-Sussman <su...@collab.net> wrote:
> *** An open question to this list:
>
> What exactly does CVS do, and how does it justify the behavior?
> What do CVS users think of it?
The attached file shows what CVS currently does.
As for subversion, I can live with the current behavior or the simple
behavior but don't really like the complex behavior. The current behavior
with a switch for simple behavior would be nice.
Just my $.05 (pennies should be discontinued)
Michael