You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Oliver Betz <li...@gmx.net> on 2005/07/07 20:12:32 UTC
Status of meta-data-versioning (mod time)?
Hello All,
sorry if this has been discussed recently, the mailing list archive
dies repeatedly with different error messages so I couldn't read
everything.
Is there any chance that "meta-data-versioning" (of modification
time) will be available soon in a release version?
Does it work time zone independent (UTC)?
TIA,
Oliver
--
Oliver Betz, Muenchen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Status of meta-data-versioning (mod time)?
Posted by Oliver Betz <li...@gmx.net>.
Ben Collins-Sussman wrote:
> > In their world, every project seems to be started under version
> > control. Well, that's not the real world.
>
> Not true at all. Rather, we expect that 90% of the time, projects
> will be 'svn import'ed into subversion.
in which state/age? My "embedded" industrial applications are rather
long-lived, stuff from 1993 (long before I thought about using
version control) is still maintained.
IMHO the timestamp is a rather meaningful property if there is no
equivalent information in the revision log.
Well, with a small script I can (and will) add/commit each file at a
time and tweak the commit time, this way the project history keeps
similar information as if being under version control from the
beginning. But it's a rather ugly (and slooow) hack.
> Once the project is in subversion's repository, tell me why you still
> care about the original timestamps. I'd like to know. The answer I
People gave already many reasons in past threads, for example
handling files not being source text, files from external sources.
Another reason: As long as there is any connection to the "pre-svn"
status of the project, the timestamp is a important indicator or
helpful to find the connection.
For example, there might be more than one version (branch) from "pre-
svn" ages, those files can be identified/compared by their timestamp.
After modifying a file the first time under version control, the
original timestamp is usually (!) no more important, since commit
time is as good as mtime in most (not necessarily all) cases.
I also agree with others that svn should be able to "touch" the
affected local files on commit so that the working copy has the same
timestamp as the commited revision. This would cause "make" to
compile the files again (as it would happen using substitutions), but
one had at least identical working copies (if using use-commit-
times).
> always hear is, "I have a whole bunch of scripts that depend on
> timestamps to perform copy synchronizations!"... to which I'm not
> sympathetic.
Situations where this is really important may be rare but existing
(files from external sources).
Oliver
--
Oliver Betz, Muenchen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Status of meta-data-versioning (mod time)?
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Monday 11 July 2005 15:21, Ben Collins-Sussman wrote:
> On Jul 11, 2005, at 5:47 AM, Oliver Betz wrote:
> > In their world, every project seems to be started under version
> > control. Well, that's not the real world.
>
> Not true at all. Rather, we expect that 90% of the time, projects
> will be 'svn import'ed into subversion.
>
> Once the project is in subversion's repository, tell me why you still
> care about the original timestamps. I'd like to know. The answer I
> always hear is, "I have a whole bunch of scripts that depend on
> timestamps to perform copy synchronizations!"... to which I'm not
> sympathetic.
Well, others just have to do things with files which don't involve
subversion ... maybe sending and receiving from third parties (where
timestamps are a simpler [and for big files faster] way to check than
hashes), maybe there's some medium or endpoint involved where it's not
possible to do a full subversion chain (think mirrors and svk) ...
Not everyone has complete control over the working data.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Status of meta-data-versioning (mod time)?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On 11.07.2005, at 15:21, Ben Collins-Sussman wrote:
> On Jul 11, 2005, at 5:47 AM, Oliver Betz wrote:
>
>> In their world, every project seems to be started under version
>> control. Well, that's not the real world.
>
> Not true at all. Rather, we expect that 90% of the time, projects
> will be 'svn import'ed into subversion.
>
> Once the project is in subversion's repository, tell me why you
> still care about the original timestamps. I'd like to know. The
> answer I always hear is, "I have a whole bunch of scripts that
> depend on timestamps to perform copy synchronizations!"... to which
> I'm not sympathetic.
How about "I'd like to know, before I imported this into Subversion,
when the last time was that I edited some file."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Status of meta-data-versioning (mod time)?
Posted by Oliver Betz <li...@gmx.net>.
Dirk Schenkewitz <sc...@docomolab-euro.com> wrote:
> >>- People, including me, want to know "when was the last change to
> >> that file?", even if the file was laying around for some time
> >> (months/years!) before being put under subversion control. This
> >> problem cannot be solved using --use-commit-times.
> >
> > It can if you make one commit per file on initial import. Slow and
> > ugly, but it works tolerably.
>
> No, it does not work at all. "use-commit-times = yes" sets the mtime
> of a checked out file to the time of the commit, the original mtime is
> lost when the next one does a checkout that creates this file. I just
right, but the commit shouldn't be so long past the modification, so
you get approximately the time when the file was modified last.
My problem was to keep the timestamp on initial import of "legacy"
projects.
BTW: I repeat my suggestion that a commit using "use-commit-times"
should "touch" the files so that the wc has the same timestamp as the
commit time.
> tested, with "use-commit-times = yes":
[example snipped]
> If you do commits for each single file at a time, you can keep the
> *order* of the original mtimes, that's all.
in your example, you added the file without tweaking the svn:date
property of the commit.
[my "adjust commit time" hack]
> If I may I ask: How do you do that? Maybe it is your hack that would
see below. Comments welcom, I'm not a Perl monk.
Oliver
- snip -
#!/usr/bin/perl
# import files to subversion one by one and adjust commit date to file's mtime
# this method is extremly slow!
# directory timestamps are not kept ad commits are not in chronological order
# 2005-07-11 Oliver Betz
# caution: stat() fails on filenames with foreign characters.
# maybe conflicting translations from svn and perl?
use strict;
use HTTP::Date qw(time2isoz);
use File::stat; # by-name access to mtime
my $rev; # revision of committed file
my @svnstat; # list of files
my $filename; # path to current file
my $mtime; # mtime of current file
my $more = 1; # process more directories
$ENV{Lang}="C"; # else we might get localized responses
while ($more){
$more = 0; # assume we had nothing more to do
@svnstat = split /\n/, `svn stat`; # get all (not ignored) files
foreach (@svnstat) {
next unless $_ =~ /^\?.....\s+(\S.+)$/; # use only files not yet under version control
$filename = $1;
if (-d $filename) {$more = 1}; # we add another directory -> repeat loop
$mtime = (stat($filename))->mtime;
print `svn add -N "$filename"`; # put under svn control
$rev=`svn ci -m "mtime keeping add of $filename"`; # commit this file immediately
print "$rev"; # complete response (several lines)
die "wrong response $rev" unless $rev =~ /Committed revision (\d+)\./;
$rev = $1; # numerical value -> $rev
$mtime = time2isoz($mtime);
$mtime =~ s/\s/T/; # special format of svn time: 2005-07-11T09:17:35.000000Z
$mtime =~ s/Z/.000000Z/; # svn time has us resolution
`svn propset svn:date $mtime --revprop -r $rev`;
};
}
print "ready\n";
__END__
--
Oliver Betz, Muenchen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Status of meta-data-versioning (mod time)?
Posted by Dirk Schenkewitz <sc...@docomolab-euro.com>.
Oliver Betz wrote:
> Dirk Schenkewitz wrote:
> ...
>>- People, including me, want to know "when was the last change to
>> that file?", even if the file was laying around for some time
>> (months/years!) before being put under subversion control. This
>> problem cannot be solved using --use-commit-times.
>
>
> It can if you make one commit per file on initial import. Slow and
> ugly, but it works tolerably.
No, it does not work at all. "use-commit-times = yes" sets the mtime
of a checked out file to the time of the commit, the original mtime
is lost when the next one does a checkout that creates this file.
I just tested, with "use-commit-times = yes":
---------------------------------------------
nobody:/B/test1/trunk> cp -av /usr/src/daemontools-0.76/src/CHANGES .
nobody:/B/test1/trunk> svn add CHANGES
A CHANGES
nobody:/B/test1/trunk> svn ci
Adding trunk/CHANGES
Transmitting file data .
Committed revision 7.
nobody:/B/test1/trunk> svn up
At revision 7.
nobody:/B/test1/trunk> ll -tr
...
-rw-r--r-- 1 nobody nobody 3361 2001-07-12 18:49 CHANGES
-rw-r--r-- 1 nobody nobody 0 2005-05-20 15:52 1
-rw-r--r-- 1 nobody nobody 0 2005-06-02 17:40 2
...
# Note that the date is still "2001-07-12",
# 'svn up' did not change that.
nobody:/B/test1/trunk> cd ../..
nobody:/B> svn co svn://server/_test_ test2
...
Checked out revision 7.
nobody:/B> cd test2/trunk/
nobody:/B/test2/trunk> ll -tr
...
-rw-r--r-- 1 nobody nobody 0 2005-05-20 15:52 1
-rw-r--r-- 1 nobody nobody 0 2005-06-02 17:40 2
-rw-r--r-- 1 nobody nobody 3361 2005-07-12 19:14 CHANGES
...
# Now "CHANGES" is not the oldest file, it is the youngest,
# the mtime is "2005-07-12", just by chance this is exactly
# 4 years later :)
---------------------------------------------
If you do commits for each single file at a time, you can keep the
*order* of the original mtimes, that's all.
>>Since Oliver's problem is the nonexistence of a windows build of
>>subversion with the meta-data patches, there might be a solution:
>
>
> not only. If Phil Marek's solution remains a patch, it will always
> be some effort to make it working in a new version. I would use the
> solution only if it is in the main version.
Oh. I thought I had a good idea.
> If not, and if I needed the timestamp, I likely would use another
> method, e.g. hook scripts saving the mtime in a file property. But
> at the moment, I can live with my "adjust commit time" hack.
If I may I ask: How do you do that? Maybe it is your hack that would
solve my problem of (not wanting to but anyway) loosing the original
mtime.
"use-commit-times = yes" on its own just turned out to be less
useful than I thought.
Best regards
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Status of meta-data-versioning (mod time)?
Posted by Oliver Betz <li...@gmx.net>.
Dirk Schenkewitz wrote:
[...]
> - These informations are stored and presented by every unix/linux
> filesystem. Not storing them renders this part of the filesystem
> useless. Why did the developers of the filesystems take the effort
although I wouldn't express it this way ("useless"), it's IMO indeed
one of the most important metadata properties of a file.
Reading the announcement at http://subversion.tigris.org/
"Directories, renames, and file meta-data are versioned" I expected
that at least the modification time of a file is saved, not only the
"execute" flag (which isn't even supported by each platform).
Not doing so should be stated at least in the FAQ.
> to implement it? Because there is some use to it, whatever it may
> be, perhaps something I never thought of.
> - People, including me, want to know "when was the last change to
> that file?", even if the file was laying around for some time
> (months/years!) before being put under subversion control. This
ack. Especially if there is some relation from "pre svn" times to
other "non svn" versions of the file. Or other situations where files
are related to external sources.
> problem cannot be solved using --use-commit-times.
It can if you make one commit per file on initial import. Slow and
ugly, but it works tolerably.
> In general, when putting something under a VCS, I want to loose
> *as little information as possible*.
I agree.
> Since Oliver's problem is the nonexistence of a windows build of
> subversion with the meta-data patches, there might be a solution:
not only. If Phil Marek's solution remains a patch, it will always be
some effort to make it working in a new version. I would use the
solution only if it is in the main version.
If not, and if I needed the timestamp, I likely would use another
method, e.g. hook scripts saving the mtime in a file property. But at
the moment, I can live with my "adjust commit time" hack.
Oliver
--
Oliver Betz, Muenchen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Status of meta-data-versioning (mod time)?
Posted by Scott Palmer <sc...@2connected.org>.
On 12-Jul-05, at 11:48 AM, Ben Collins-Sussman wrote:
>
> On Jul 12, 2005, at 7:38 AM, Oliver Betz wrote:
>
>>
>> BTW: was there a good reason to make "use-commit-times" a global
>> setting?
>
> No, that was a mistake. It should have been a commandline option.
Why not both? It might make sense to generalize the concept. Let
any boolean command line option be specified in the global config so
the user can control the defaults.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Status of meta-data-versioning (mod time)?
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jul 12, 2005, at 7:38 AM, Oliver Betz wrote:
>
> BTW: was there a good reason to make "use-commit-times" a global
> setting?
>
No, that was a mistake. It should have been a commandline option.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Status of meta-data-versioning (mod time)?
Posted by Oliver Betz <li...@gmx.net>.
Branko Äibej wrote:
['make' and update to older revision with 'use-commit-times']
> If you preserve commit times in the WC, then after the update to an
> older revision, some files that need rebuilding will have changed, but
> make won't notice because their timestamps would be older than the
> timestamps of the generated files left over from the previous build.
> Such an update would force you ro do a clean rebuild, and that's not
> nice.
In many cases it doesn't happen so often to "update" to an earlier
version, and in many cases it doesn't take so much time to rebuild
all (faster than a Doxygen run), so for many people that's no problem
at all.
After all, one can choose whether to use commit times (or original
modification time) or the actual time.
As far as I could read from the older threads, that's the main
(only?) argument against "use-commit-times" (or keeping original
timestamps), am I missing something?
BTW: was there a good reason to make "use-commit-times" a global
setting?
Oliver
--
Oliver Betz, Muenchen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Status of meta-data-versioning (mod time)?
Posted by Saulius Grazulis <gr...@akl.lt>.
On Tuesday 12 July 2005 14:49, Branko Čibej wrote:
> > - 'make' uses them. If the right order is preserved,
> ..
> I've heard this argument many times, and it's simply *wrong*. Imagine
> this scenario:
>
> * update to HEAD
> * make clean all
> * update to some older revision
> * make all
Well, I guess your scenario contains a mistake:
* update to some older revision
* make clean all
will funcion as intended, provided you makefiles are correct. Given that
downgrading a WC is not done frequently, 'make clean all' is not a big deal.
Make is not a panacea, but in this case one can use make to get reliable
results.
> If you preserve commit times in the WC, then after the update to an
> older revision, some files that need rebuilding will have changed, but
> make won't notice because their timestamps would be older than the
> timestamps of the generated files left over from the previous build.
> Such an update would force you ro do a clean rebuild, and that's not nice.
>
> The argument assumes that generated files are under version control,
> too, but that's usually not the case.
This depends on the working style and on te working setup. I do admit that in
many _software development_ projects only sources are kept in the repository,
updates are often, and chekout times are just the right thing.
What makes a difference are projects that need to version generated files, or
that need to preserve true modification times for some reason.
--
Saulius Gražulis
Visuomeninė organizacija "Atviras Kodas Lietuvai"
P.Vileišio g. 18
LT-10306 Vilnius
Lietuva (Lithuania)
tel/fax: (+370-5)-210 40 05
mobilus: (+370-684)-49802, (+370-614)-36366
Re: Status of meta-data-versioning (mod time)?
Posted by Branko Čibej <br...@xbc.nu>.
Dirk Schenkewitz wrote:
> - 'make' uses them. If the right order is preserved, this could also
> be solved using --use-commit-times, but right now I believe that
> the right order is not preserved.
I've heard this argument many times, and it's simply *wrong*. Imagine
this scenario:
* update to HEAD
* make clean all
* update to some older revision
* make all
If you preserve commit times in the WC, then after the update to an
older revision, some files that need rebuilding will have changed, but
make won't notice because their timestamps would be older than the
timestamps of the generated files left over from the previous build.
Such an update would force you ro do a clean rebuild, and that's not nice.
The argument assumes that generated files are under version control,
too, but that's usually not the case.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Status of meta-data-versioning (mod time)?
Posted by Dirk Schenkewitz <sc...@docomolab-euro.com>.
kfogel@collab.net wrote:
> Scott Palmer <sc...@2connected.org> writes:
> ...
>>In any case, I thought I had read on the list of a patch that has
>>already been made available. So the cost appears relatively low. If
>>the development team considers this a low priority (and I agree that
>>it is), it appears that the cost is in proper proportion to the
>>benefits.
>
>
> That's how I'd sum things up too. Note that the real cost is the cost
> of evaluating that patch and the design behind it, which (so far) has
> looked pretty high. The mere existence of the patch doesn't change
> that cost.
Is there any way to reduce these costs, I mean could I do something
about it?
What is meant by "evaluating that patch and the design behind it",
can you describe what is usually done (in a few sentences, it shouldn't
cost you a lot of time) or give a link to that information?
Reasons why I want to have it:
- Tar files store it. I want to be able to give some stuff to someone
else in the form of a tar file. If I want to give him/her a new
version, taken from a freshly checked out WC, then all timestamps
are different from the old version, even though there are changes
in a few files only (this could be solved using --use-commit-times,
maybe, at least to some extend).
- 'make' uses them. If the right order is preserved, this could also
be solved using --use-commit-times, but right now I believe that
the right order is not preserved.
- These informations are stored and presented by every unix/linux
filesystem. Not storing them renders this part of the filesystem
useless. Why did the developers of the filesystems take the effort
to implement it? Because there is some use to it, whatever it may
be, perhaps something I never thought of.
- People, including me, want to know "when was the last change to
that file?", even if the file was laying around for some time
(months/years!) before being put under subversion control. This
problem cannot be solved using --use-commit-times.
In general, when putting something under a VCS, I want to loose
*as little information as possible*.
Since Oliver's problem is the nonexistence of a windows build of
subversion with the meta-data patches, there might be a solution:
Branko, could we somehow convince you to build a windows build of
the meta-data version, after the problem with zlib got sorted out?
Please? :)
Have fun
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Status of meta-data-versioning (mod time)?
Posted by kf...@collab.net.
Scott Palmer <sc...@2connected.org> writes:
> I'm sorry, I choose my words poorly. I should have said the
> developers seem to attach little value to the fact that other tools
> use time stamps. Though it is funny that you bring this point up,
> since it was the phrase "I'm not sympathetic" which I reacted to in a
> similar way (I used it myself merely to point that out). It also
> implies a certain attitude. (An unsympathetic one :-) ) Suggesting
> that the people making the request have not put sufficient thought
> into the request or effort into changing their work flow in the first
> place. I don't think that is what is happening in this case.
Yeah, "unsympathetic" was a bit abrupt. Of course you're right, Ben
didn't mean it as a putdown at all.
> In any case, I thought I had read on the list of a patch that has
> already been made available. So the cost appears relatively low. If
> the development team considers this a low priority (and I agree that
> it is), it appears that the cost is in proper proportion to the
> benefits.
That's how I'd sum things up too. Note that the real cost is the cost
of evaluating that patch and the design behind it, which (so far) has
looked pretty high. The mere existence of the patch doesn't change
that cost.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Status of meta-data-versioning (mod time)?
Posted by Scott Palmer <sc...@2connected.org>.
On 11-Jul-05, at 2:08 PM, kfogel@collab.net wrote:
> There's a certain attitude that comes up too frequently, when people
> propose features and the Subversion committers don't react with
> sufficient enthusiasm :-). Here that thought was expressed in
>
> "it seems the developers ignore the fact that other tools use
> time stamps"
>
> We don't "ignore" much around here. What we do is make cost/benefit
> analyses. ...[snip]
>
> So I'm not complaining about the substantive content of your mail.
> However, I and the other developers do not appreciate inaccurate
> accusations that we are "ignoring" arguments when we are instead
> acknowledging those arguments, engaging them critically, and weighing
> them against counterarguments.
I'm sorry, I choose my words poorly. I should have said the
developers seem to attach little value to the fact that other tools
use time stamps. Though it is funny that you bring this point up,
since it was the phrase "I'm not sympathetic" which I reacted to in a
similar way (I used it myself merely to point that out). It also
implies a certain attitude. (An unsympathetic one :-) ) Suggesting
that the people making the request have not put sufficient thought
into the request or effort into changing their work flow in the first
place. I don't think that is what is happening in this case.
But enough of that.. I don't think Ben intended to put down the
users any more than I intended to put down the developers. If I
didn't think Subversion was an excellent tool as it is, I wouldn't be
using it. Our R&D dept. switched over to Subversion at the beginning
of this year based on my pushing, and just a few weeks ago my boss
mentioned "I'm so glad we switched to Subversion"
In any case, I thought I had read on the list of a patch that has
already been made available. So the cost appears relatively low. If
the development team considers this a low priority (and I agree that
it is), it appears that the cost is in proper proportion to the
benefits.
There was also a similar discussion that started off about Mac
resource forks, and became a general idea to version "extended
attributes". It seemed to have promise, but I haven't heard anything
about it for a long time.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Status of meta-data-versioning (mod time)?
Posted by kf...@collab.net.
Scott Palmer <sc...@2connected.org> writes:
> If Subversion is going to throw away metadata that most other file
> operations (most copy, ftp, http file transfers for example)
> preserve, e.g. mod times, then the onus is on it to justify that.
> So far the answer I always hear is, "always use subversion to track
> file versions"... to which I'm not sympathetic. :-)
>
> I have no desire or ability to force everyone and everything I
> exchange data with to use Subversion exclusively. Mod times would
> work fine for tracking file versions, if tools like Subversion didn't
> break them (and insist they were useless in the first place because
> some other tool might break them as well).
>
> There are plenty of existing tools and/or scripts out there that do
> their work based on time stamps. Subversion itself argues that
> 'make' only works properly if the time stamps are just so. It is the
> reason often quoted for NOT tracking the file mod times... and yet it
> seems the developers ignore the fact that other tools use time stamps
> in similar ways and work best when the mod time is accurately tracked.
>
> Why should everyone change their workflow to accommodate the fact
> that subversion doesn't save meta-data? That "whole bunch of
> scripts" may be difficult or impossible to change. Filesystems keep
> track of mod times for a reason. Why does subversion assume that
> reason goes away completely with a VCS in place? The OS' filesystem
> is still there! You don't assume 'make' is integrated with
> Subversion, why assume everything else must be?
There's a certain attitude that comes up too frequently, when people
propose features and the Subversion committers don't react with
sufficient enthusiasm :-). Here that thought was expressed in
"it seems the developers ignore the fact that other tools use time stamps"
We don't "ignore" much around here. What we do is make cost/benefit
analyses. We try to determine the cost of of a feature (including
implementation, maintenance of the code forever after, documentation,
and fielding future user questions about edge cases) and compare that
to the benefits (a new ability in Subversion, no longer having to
field user questions about the feature's lack, etc).
Sometimes we decide the benefit isn't worth the cost. Such
determinations are always subject to future re-evaluation, of course.
Maybe someone will point out a benefit no one had thought of before,
or propose a clever implementation that reduces the cost. Conclusions
are always tentative, in the sense that they're not meant to close off
further discussion.
So I'm not complaining about the substantive content of your mail.
However, I and the other developers do not appreciate inaccurate
accusations that we are "ignoring" arguments when we are instead
acknowledging those arguments, engaging them critically, and weighing
them against counterarguments. I believe several developers have done
so in this thread (or in previous threads on the same topic, if not in
this exact thread). Just because they didn't come to the conclusion
you wanted doesn't mean they ignored the arguments in favor of that
conclusion! :-)
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Status of meta-data-versioning (mod time)?
Posted by Scott Palmer <sc...@2connected.org>.
On 11-Jul-05, at 9:21 AM, Ben Collins-Sussman wrote:
> Once the project is in subversion's repository, tell me why you
> still care about the original timestamps. I'd like to know. The
> answer I always hear is, "I have a whole bunch of scripts that
> depend on timestamps to perform copy synchronizations!"... to which
> I'm not sympathetic.
If Subversion is going to throw away metadata that most other file
operations (most copy, ftp, http file transfers for example)
preserve, e.g. mod times, then the onus is on it to justify that.
So far the answer I always hear is, "always use subversion to track
file versions"... to which I'm not sympathetic. :-)
I have no desire or ability to force everyone and everything I
exchange data with to use Subversion exclusively. Mod times would
work fine for tracking file versions, if tools like Subversion didn't
break them (and insist they were useless in the first place because
some other tool might break them as well).
There are plenty of existing tools and/or scripts out there that do
their work based on time stamps. Subversion itself argues that
'make' only works properly if the time stamps are just so. It is the
reason often quoted for NOT tracking the file mod times... and yet it
seems the developers ignore the fact that other tools use time stamps
in similar ways and work best when the mod time is accurately tracked.
Why should everyone change their workflow to accommodate the fact
that subversion doesn't save meta-data? That "whole bunch of
scripts" may be difficult or impossible to change. Filesystems keep
track of mod times for a reason. Why does subversion assume that
reason goes away completely with a VCS in place? The OS' filesystem
is still there! You don't assume 'make' is integrated with
Subversion, why assume everything else must be?
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Status of meta-data-versioning (mod time)?
Posted by Saulius Grazulis <gr...@akl.lt>.
On Monday 11 July 2005 16:21, Ben Collins-Sussman wrote:
> Once the project is in subversion's repository, tell me why you still
> care about the original timestamps. I'd like to know. The answer I
> always hear is, "I have a whole bunch of scripts that depend on
> timestamps to perform copy synchronizations!"... to which I'm not
> sympathetic.
There is much more than just a "bunch of scripts" that relies on mtime -- it
is The Make System ;).
Now, while many software dev. projects only keep sources in the repository,
there are some software projects, as well as _non-software development_
projects that need to have make-built files versioned as well. There was a
discussion about his some time ago, so I don't want to repeat it, just to
point this out.
Now, obviously, if mtimes are messed up then 'make' gets confused, and so are
the users. ;).
Time-stamp preservation is what helps me 90% of the time. I do use 'mod time'
versioning from Marek's branch all the time. No go without it.
Still, there is a possibility of race condition leading incorrect make-builds
when using genuine time-stamps. (I guess I posted once an example).
Even better solution for this purpose would probably be to ensure that commit
times of the files preserve the order of mtimes (i.e. commit oldest files
first, newest files last and stamp them accordingly). This would eliminate
the race condition.
However, mtimes are more logical and also serve other peoples needs.
--
Saulius Gražulis
Visuomeninė organizacija "Atviras Kodas Lietuvai"
P.Vileišio g. 18
LT-10306 Vilnius
Lietuva (Lithuania)
tel/fax: (+370-5)-210 40 05
mobilus: (+370-684)-49802, (+370-614)-36366
Re: Status of meta-data-versioning (mod time)?
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jul 11, 2005, at 5:47 AM, Oliver Betz wrote:
>
> In their world, every project seems to be started under version
> control. Well, that's not the real world.
Not true at all. Rather, we expect that 90% of the time, projects
will be 'svn import'ed into subversion.
Once the project is in subversion's repository, tell me why you still
care about the original timestamps. I'd like to know. The answer I
always hear is, "I have a whole bunch of scripts that depend on
timestamps to perform copy synchronizations!"... to which I'm not
sympathetic.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Status of meta-data-versioning (mod time)?
Posted by Oliver Betz <li...@gmx.net>.
Ph. Marek wrote:
> > Is there any chance that "meta-data-versioning" (of modification
> > time) will be available soon in a release version?
> Please see issue 1256
> (http://subversion.tigris.org/issues/show_bug.cgi?id=1256) and the
> thread at
> http://marc.theaimsgroup.com/?l=subversion-dev&m=111459962412224&w=2,
> and possibly here
> http://marc.theaimsgroup.com/?l=subversion-dev&m=111795919812110&w=2
I have been reading all this, but wanted to know whether this will be
integrated to the _release_ version soon. Building a Windows version
doesn't seem to be funny.
In the mean I found a thread ("original timestamp preservation") in
the developer list http://svn.haxx.se/dev/archive-2005-06/
Reading this, it doesn't seem that timestamp preservation will be
implemented soon. Importing legacy files' metadata etc. doesn't seem
to be considered important by the developers.
In their world, every project seems to be started under version
control. Well, that's not the real world.
So I made a Perl version of Molle Bestefich's bash script in perl (no
bash available here) to import a tree with one commit per file and
setting the commit time to the mtime. It's a bit crude at the moment
because I can't decide whether to sort the commits by date (see other
thread regarding this).
> > Does it work time zone independent (UTC)?
> AFAIK yes.
That's IMHO important. File dates must not be location dependant.
Oliver
--
Oliver Betz, Muenchen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Status of meta-data-versioning (mod time)?
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
> sorry if this has been discussed recently, the mailing list archive
> dies repeatedly with different error messages so I couldn't read
> everything.
>
> Is there any chance that "meta-data-versioning" (of modification
> time) will be available soon in a release version?
Please see issue 1256
(http://subversion.tigris.org/issues/show_bug.cgi?id=1256) and the thread at
http://marc.theaimsgroup.com/?l=subversion-dev&m=111459962412224&w=2, and
possibly here
http://marc.theaimsgroup.com/?l=subversion-dev&m=111795919812110&w=2
> Does it work time zone independent (UTC)?
AFAIK yes.
> TIA,
>
> Oliver
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org