You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by tr...@clayst.com on 2005/06/03 13:13:23 UTC
Timestamp Frustrations
I am curious if anyone else has solved this problem. I asked about it
many months ago and no one had.
I am managing (more like, attempting to manage) a single-developer web
project with svn. The use of timestamps is embedded in my work style
and practice in a number of ways, including simply looking at what I've
changed lately, and routine copying of changed files between machines
based on date.
I attempted to write a wrapper script for the most common svn commands
which properly handles setting a timestamp property for each file when
it is added to or updated in the repository, then retrieving that and
using touch to set the file time when the file is checked out. However
this is incomplete at best (I keep discovering places where svn touches
the files that I hadn't thought of, and having to reconstruct timestamp
data), and it's cumbersome to maintain and use.
I realize that in parallel development you need the timestamp to
reflect the last commit or last checkout etc., for eample to make
builds work properly when other people's changes come into a local
working copy. But in a single-developer environment sometimes this
approach causes the loss of valuable information about the time the
file was actually last modified.
Has there been any thought to allowing svn to preserve the file
timestamp which reflects the normal OS meaning -- time of last
modification to the content -- instead of time of last version control
action or time of last commit? Anyone have a simple, reliable way to
do this now?
I am doing this work on Windows but the concerns are not OS-specific
since file timestamps generally have the same meaning in most typical
OS's.
Thanks,
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Frustrations
Posted by tr...@clayst.com.
On 3 Jun 2005 Ben Collins-Sussman wrote:
> 'svn merge', on the other hand, is just shortcut for making local
> edits. It's no different than opening files in your editor and
> tweaking them. And in that case, you definitely don't want the
> timestamps reset. At a minimum, it would make 'svn status' quite
> slow at detecting edited files. It would be a bit unnatural.
Well OK, then maybe I don't understand merge. I gather I would be far
from the first :-).
I have two main branches of development:
project/live
project/dev
Each one has a couple of subdirectories below it. I keep working
copies of both. Sometimes I make bug fixes to the live/ working copy;
these I usually commit and publish right away. Most changes are in the
dev/ working copy, and I don't commit these very often.
The last time live/ was copied to dev/ was r3. I recently finished a
bunch of changes to dev/ and was ready to make them live. I committed
them from the dev/ working copy. Then from the live/ working copy I
did the svn log --top-on-copy to discover that r3 was what I wanted.
Then I did this, also from the live/ working copy:
svn update
svn merge -r 3:HEAD file:///h:/svnrepos/project/dev/
[resolved conflicts]
svn commit -m "Merge XXX modifications into live branch"
Is this correct? I took it from the "Merging a Whole Branch to
Another" section of the book.
For timestamps, what I really want here is for the files in the live/
wc to have the same timestamps as they had in the dev/ wc -- i.e. the
last time the file was actually modified (putting aside any mods to
resolve conflicts). So unless I'm using merge incorrectly, I think
this is a case where you would want merge to preserve the timestamps,
if they were being preserved at all.
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merge Help
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jun 4, 2005, at 7:03 AM, trlists@clayst.com wrote:
>
> Re the earlier discussion on timestamps, what I really want here is
> for
> the files in the live/ wc to have the same timestamps as they had in
> the dev/ wc -- i.e. the last time the file was actually modified
> (putting aside any mods to resolve conflicts). So unless I'm using
> merge incorrectly, I think this is a case where you would want
> merge to
> preserve the timestamps, if they were being preserved at all.
>
I understand your point, it makes sense. In other words, if
subversion were versioning timestamps/owner/permission metadata, then
that stuff would be preserved when porting changes, just the way file
contents are preserved.
Unfortunately, subversion doesn't version filesystem metadata. The
current design is such that when you import files into the subversion
repository, you're moving them to a new filesystem (the repository),
and it then generates its *own* filesystem metadata: last-commit-
time, last-author, last-changed-rev, filesize. This is all the stuff
that 'svn ls -v URL' shows. All of the original metadata is lost.
The working copy is just a disposable shadow of the 'real'
filesystem, so you need to switch paradigms here. Instead of using
OS timestamps to copy stuff between working copies, use the *real*
filesystem to do the syncing -- that is, the repository. 'svn
commit' when you need to save your work, 'svn update' on another box
to get the changes in progress. The svn repository is capable of
doing everything that your timestamp-syncing script is already
doing; you just need to embrace it as the center of your workflow now.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Merge Help
Posted by tr...@clayst.com.
I am reposting this from another thread because it got no response, and
I'd be interested in some feedback as to whether this is the correct
use of merge ...
> 'svn merge', on the other hand, is just shortcut for making local
> edits. It's no different than opening files in your editor and
> tweaking them. And in that case, you definitely don't want the
> timestamps reset. At a minimum, it would make 'svn status' quite
> slow at detecting edited files. It would be a bit unnatural.
Well OK, then maybe I don't understand merge. I gather I would be far
from the first :-).
I have two main branches of development:
project/live
project/dev
Each one has a couple of subdirectories below it. I keep working
copies of both. Sometimes I make bug fixes to the live/ working copy;
these I usually commit and publish right away. Most changes are in the
dev/ working copy, and I don't commit these very often.
The last time live/ was copied to dev/ was r3. I recently finished a
bunch of changes to dev/ and was ready to make them live. I committed
them from the dev/ working copy. Then from the live/ working copy I
did the svn log --top-on-copy to discover that r3 was what I wanted.
Then I did this, also from the live/ working copy:
svn update
svn merge -r 3:HEAD file:///h:/svnrepos/project/dev/
[resolved conflicts]
svn commit -m "Merge XXX modifications into live branch"
Is this correct? I took it from the "Merging a Whole Branch to
Another" section of the book.
Re the earlier discussion on timestamps, what I really want here is for
the files in the live/ wc to have the same timestamps as they had in
the dev/ wc -- i.e. the last time the file was actually modified
(putting aside any mods to resolve conflicts). So unless I'm using
merge incorrectly, I think this is a case where you would want merge to
preserve the timestamps, if they were being preserved at all.
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Frustrations
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jun 3, 2005, at 9:11 AM, trlists@clayst.com wrote:
>
> Incidentally, why doesn't use-commit-times affect svn merge?
Merges are fundamentally different than checkouts or updates.
Checkouts and updates modify the 'base' versions of files in your
working copy: not just the working files, but the underlying
administrative data.
'svn merge', on the other hand, is just shortcut for making local
edits. It's no different than opening files in your editor and
tweaking them. And in that case, you definitely don't want the
timestamps reset. At a minimum, it would make 'svn status' quite
slow at detecting edited files. It would be a bit unnatural.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Timestamp Frustrations
Posted by tr...@clayst.com.
On 3 Jun 2005 Dale Worley wrote:
> You might want to look into the Unison file synchronizer, which
> copies changed files based on their contents, which is much more
> robust. (It also keeps the timestamps aligned, if you want.)
Thanks, that looks quite interesting. I'll look at it.
> Check through the archived mailing lists. IIRC, there's been
> significant work on a Subversion option so that when Subversion
> updates a WC file, it changes its modification time to be when that
> version of the file was committed to the repository.
That appears to be present in the use-commit-times option in the config
file. What I need would be one step further, a use-file-times option
which would automatically preserve the file time in a property and then
restore it on checkout, update, revert, switch, or merge.
Incidentally, why doesn't use-commit-times affect svn merge? I must be
missing something in how I understand merges, because I would expect it
to have the same effect on merge as on checkout etc.
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Frustrations
Posted by tr...@clayst.com.
On 3 Jun 2005 James Berry wrote:
> Sounds to me like maybe you just want rsync.
I might, if this were a Linux environment. But it's Windows. I see
that one can use rsync on Windows via Cygwin but it appears to be
fairly involved to set up.
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Frustrations
Posted by Thomas Moschny <mo...@ipd.uni-karlsruhe.de>.
On Friday 03 June 2005 17:15, trlists@clayst.com wrote:
> > I'm not sure I understand; is there some difference between "commit
> > changes" and "copy files from one machine to another?" Either you're
> > ready to broadcast work to other computers, or you're not.
>
> The two computers are both used by me. One is a desktop and one is a
> laptop. I move back and forth between them often, depending on where,
> how, and when I'm working, and whether I need to take work out of the
> house. I tend to use commit when I'm done with something, which is not
> at all synchronized with switching machines.
Maybe you could use a 'private' devel branch to lower the (psychological)
barrier of doing a check-in?
Then, when some part of your work is finished, you could finally propagate
(merge) it into the main branch.
Regards,
Thomas
Re: Timestamp Frustrations
Posted by tr...@clayst.com.
On 3 Jun 2005 Ben Collins-Sussman wrote:
> Well, using version control means changing your practices. There's
> no such thing as transparent version control. :-)
Fair enough :-).
> If the repository is FSFS-backed, rather than BDB, then it's fine to
> access directly via file:/// over a network share. Otherwise: why
> not just run a trivial 'svnserve' daemon and use a real network?
> It's dead simple to set up, and will probably work faster than SMB.
I could do this if I wanted to. My network consists of four Windows
machines; and two Linux machines (fileserver and firewall), both
running Slackware. I normally access the fileserver from Windows via
SMB but I could put the repository on there easily and use svnserve.
However, since I currently store in on one Windows machine and don't
mind opening it for sharing inside the network, leaving it there and
using file:/// from the other also works, and as they say it ain't
broke.
> Doubles the complexity? Just use your current script for
> unversioned things. Use 'svn commit' and 'svn up' for the
> versioned stuff; the svn commands don't even need to be part of a
> script.
Right now I can update with a single command (with which I have to
interact). Using svn for part of the update requires using a different
approach for those directories, and that is more complex.
> I'm not sure I understand; is there some difference between "commit
> changes" and "copy files from one machine to another?" Either you're
> ready to broadcast work to other computers, or you're not.
The two computers are both used by me. One is a desktop and one is a
laptop. I move back and forth between them often, depending on where,
how, and when I'm working, and whether I need to take work out of the
house. I tend to use commit when I'm done with something, which is not
at all synchronized with switching machines.
> > - Using svn handles only the files under version control. How do
> > I also handle unversioned files in the directories that are under
> > version control.
>
> Keep using your timestamp scripts, I guess.
Well yes, but then that script needs to know not to muck with the files
svn is updating. I'd have to put them in a separate directory, another
complexity.
> The 'live site' issue is so common, it's even an SVN FAQ:
>
> http://subversion.tigris.org/faq.html#website-auto-update
>
> Basically, you have a post-commit hook run 'svn update' on a live
> working-copy after every commit. You get automatic publishing of
> whatever has changed.
Thanks, I will look at that. I would need multiple updates as I have
both live and development sites on remote servers, and live and
development branches in the repository.
> Um, your current process sounds anything but simple to me. :-)
Ah, but I can do it without having to hardly think about it at all :-).
> The problem is that we're both speaking in generalities. Maybe if
> you posted a detailed description of your workflow, others on this
> list could prescribe a new process for you.
Well sure, here is a typical transfer:
- Do some work on project files
- Look at clock
- Uh oh, have to be at that meeting across town in 15 minutes,
then I'm going to pick up the kids, maybe I'll sit at the
library for the hour in between
- Better take the laptop
- Save files, in whatever state they're in, marking location of
current effort (usually I just stick a marker in the source)
- Close editor on desktop
- Open laptop
- Run update script to pick up changed email, project files,
correspondence, images, etc. from desktop -- only about
10% of what's copied is under version control
When I get back this is typical:
- Start work on laptop in dining room while kids play
- Oops, time to clean up for dinner
- Realize that I'll be working on desktop later
- Close editor, etc., as above
- Run update script to put what I did for the afternoon back on
desktop
You get the idea, I hope. Most of what's transferred is not under
version control, and when it is really all I'm doing in svn terms is
keeping the working copy in the same state on both machines, but
commiting little changes and half-done files does not seem to me to be
what VCS is or should be for.
The original problem here was being able to preserve timestamps, for
which I have a number of fairly conventional and legitimate uses.
Significantly altering my work practices to get the benefits of VCS
makes sense. But having to use VCS to keep my laptop synchronized with
my desktop 2 or 3 times a day is not the benefit I want from VCS, it's
added complexity for no actual benefit that I can see. If I'm changing
my practice purely to work around the way a tool is designed, and
adding complexity for no benefit just so I can do that, that seems to
me like the tail wagging the dog.
On the other hand, one might conclude from the above that svn is not
the right tool for the job I'm trying to do, but everything else I
looked had other problems that were even worse ...
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Frustrations
Posted by James Berry <ja...@jberry.us>.
On Jun 3, 2005, at 6:52 AM, trlists@clayst.com wrote:
> Any other ideas? :-)
Sounds to me like maybe you just want rsync.
-jdb
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Frustrations
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jun 3, 2005, at 8:52 AM, trlists@clayst.com wrote:
> On 3 Jun 2005 Ben Collins-Sussman wrote:
>
>
>> Why not let the version control system do this for you? Instead of
>> copying files around yourself based on timestamps, why not just have
>> a working copy on each machine? Then all you need to do is run 'svn
>> update' to get the newest things on each box.
>>
>
> Thanks Ben. I knew someone would say that :-).
>
> That works fine for that purpose. It is a significant change in
> practice but I could get used to it.
Well, using version control means changing your practices. There's
no such thing as transparent version control. :-)
>
> - Right now the repository is stored locally on one machine. Can
> I access it from the other across the (Windows) network using
> file:/// syntax if the repository drive is mapped?
If the repository is FSFS-backed, rather than BDB, then it's fine to
access directly via file:/// over a network share. Otherwise: why
not just run a trivial 'svnserve' daemon and use a real network?
It's dead simple to set up, and will probably work faster than SMB.
>
> - I manage the transfer of all kinds of other files between
> machines with a single script that uses timestamps. This approach
> would require using svn for all the files under version
> control, so
> it doubles the complexity of updating.
Doubles the complexity? Just use your current script for unversioned
things. Use 'svn commit' and 'svn up' for the versioned stuff; the
svn commands don't even need to be part of a script.
>
> - Using svn update requires a commit on one machine before
> updating on the other. I switch back and forth between machines
> sometimes 2 or 3 times a day, and often I'm not ready to commit
> the work when I just happen to need to switch machines. IOW the
> version control cycle and the between-machines update cycle are
> poorly matched. .
I'm not sure I understand; is there some difference between "commit
changes" and "copy files from one machine to another?" Either you're
ready to broadcast work to other computers, or you're not.
In the old system, you would copy stuff over via timestamps. In the
new system, you would 'svn commit', and then 'svn update'.
>
> - Using svn handles only the files under version control. How do
> I also handle unversioned files in the directories that are under
> version control.
Keep using your timestamp scripts, I guess.
>
> - There are other things I do with timestamps -- for example
> understanding if two files were changed at about the same time or
> not, looking at which files I need to upload to deploy the changes
> to my live site, etc. The way svn manages the timestamps makes
> this difficult.
The 'live site' issue is so common, it's even an SVN FAQ:
http://subversion.tigris.org/faq.html#website-auto-update
Basically, you have a post-commit hook run 'svn update' on a live
working-copy after every commit. You get automatic publishing of
whatever has changed.
>
> So it is a lot more than just saying "use svn update". It could be
> done, but it adds a lot of complexity to what is currently a
> relatively
> simple process.
>
Um, your current process sounds anything but simple to me. :-)
The problem is that we're both speaking in generalities. Maybe if
you posted a detailed description of your workflow, others on this
list could prescribe a new process for you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Frustrations
Posted by Roel Harbers <ro...@roelharbers.com>.
trlists@clayst.com wrote:
> - I manage the transfer of all kinds of other files between
> machines with a single script that uses timestamps. This approach
> would require using svn for all the files under version control, so
> it doubles the complexity of updating.
If the files are important enough to transfer between machines, why not
just add them to version control?
> - Using svn update requires a commit on one machine before
> updating on the other. I switch back and forth between machines
> sometimes 2 or 3 times a day, and often I'm not ready to commit
> the work when I just happen to need to switch machines. IOW the
> version control cycle and the between-machines update cycle are
> poorly matched. .
So your own script just copies half completed changes between machines?
If this is a workable situation for you, I don't see any problem with
committing these half completed changes to svn.
>
> - Using svn handles only the files under version control. How do
> I also handle unversioned files in the directories that are under
> version control.
Again, if it's important that they are present on these other machines,
why not just add them to svn?
> - There are other things I do with timestamps -- for example
> understanding if two files were changed at about the same time or
> not, looking at which files I need to upload to deploy the changes
> to my live site, etc. The way svn manages the timestamps makes
> this difficult.
You could use the svn log or svn diff output to see what changed. You
could also use a scripted svn export to keep the site up to date,
although that may not be a good idea when committing unfinished changes.
> So it is a lot more than just saying "use svn update". It could be
> done, but it adds a lot of complexity to what is currently a relatively
> simple process.
>
> Any other ideas? :-)
AFAIKT, the complexity stems from the combination of your script and
svn. I'd try to get rid of the script altogether. Basically, what you
are doing now is using *two* version control systems at the same time,
svn and your own script, which means, indeed, a lot of unneeded complexity.
Regards,
Roel Harbers
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Frustrations
Posted by tr...@clayst.com.
On 3 Jun 2005 Ben Collins-Sussman wrote:
> Why not let the version control system do this for you? Instead of
> copying files around yourself based on timestamps, why not just have
> a working copy on each machine? Then all you need to do is run 'svn
> update' to get the newest things on each box.
Thanks Ben. I knew someone would say that :-).
That works fine for that purpose. It is a significant change in
practice but I could get used to it. However there are a bunch of
questions and side effects:
- Right now the repository is stored locally on one machine. Can
I access it from the other across the (Windows) network using
file:/// syntax if the repository drive is mapped?
- I manage the transfer of all kinds of other files between
machines with a single script that uses timestamps. This approach
would require using svn for all the files under version control, so
it doubles the complexity of updating.
- Using svn update requires a commit on one machine before
updating on the other. I switch back and forth between machines
sometimes 2 or 3 times a day, and often I'm not ready to commit
the work when I just happen to need to switch machines. IOW the
version control cycle and the between-machines update cycle are
poorly matched. .
- Using svn handles only the files under version control. How do
I also handle unversioned files in the directories that are under
version control.
- There are other things I do with timestamps -- for example
understanding if two files were changed at about the same time or
not, looking at which files I need to upload to deploy the changes
to my live site, etc. The way svn manages the timestamps makes
this difficult.
So it is a lot more than just saying "use svn update". It could be
done, but it adds a lot of complexity to what is currently a relatively
simple process.
Any other ideas? :-)
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Frustrations
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jun 3, 2005, at 8:13 AM, trlists@clayst.com wrote:
> The use of timestamps is embedded in my work style
> and practice in a number of ways, including simply looking at what
> I've
> changed lately, and routine copying of changed files between machines
> based on date.
>
Why not let the version control system do this for you? Instead of
copying files around yourself based on timestamps, why not just have
a working copy on each machine? Then all you need to do is run 'svn
update' to get the newest things on each box.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Frustrations
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jun 3, 2005, at 9:20 AM, Jim Correia wrote:
> On Jun 3, 2005, at 9:13 AM, trlists@clayst.com wrote:
>
>
>> I am curious if anyone else has solved this problem. I asked
>> about it
>> many months ago and no one had.
>>
>> I am managing (more like, attempting to manage) a single-developer
>> web
>> project with svn. The use of timestamps is embedded in my work style
>> and practice in a number of ways, including simply looking at what
>> I've
>> changed lately, and routine copying of changed files between machines
>> based on date.
>>
>
> It sounds like use-commit-times should solve your problem.
>
> http://svnbook.red-bean.com/en/1.1/ch07.html
>
I think what he really wants is the patch to preserve original
filesystem metadata, such owner/timestamp/perms:
http://svn.collab.net/repos/svn/branches/meta-data-versioning/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Frustrations
Posted by Jim Correia <ji...@pobox.com>.
On Jun 3, 2005, at 9:13 AM, trlists@clayst.com wrote:
> I am curious if anyone else has solved this problem. I asked about it
> many months ago and no one had.
>
> I am managing (more like, attempting to manage) a single-developer web
> project with svn. The use of timestamps is embedded in my work style
> and practice in a number of ways, including simply looking at what
> I've
> changed lately, and routine copying of changed files between machines
> based on date.
It sounds like use-commit-times should solve your problem.
http://svnbook.red-bean.com/en/1.1/ch07.html
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Frustrations/ FAQ update
Posted by ph...@bmlv.gv.at.
(cc'ed to dev@ for FAQ update)
trlists@clayst.com wrote:
> I am curious if anyone else has solved this problem. I asked about it
> many months ago and no one had.
Please see http://svn.collab.net/viewcvs/svn/branches/meta-data-versioning/ for
the branch; see
http://marc.theaimsgroup.com/?l=subversion-dev&m=111459962412224&w=2 for
patches against 1.2.0rc2 (which apply with a small fuzz also against the
released version)
As this comes up and up again, it should probably be at least listed in the FAQ
(if it isn't taken into svn itself).
Regards,
Phil
Index: faq.html
===================================================================
--- faq.html (Revision 14979)
+++ faq.html (Arbeitskopie)
@@ -122,6 +122,9 @@
on Windows?</a></li>
<li><a href="#bdb-fsfs-convert">How do I convert my repository from using BDB
to FSFS or from FSF to BDB?</a></li>
+<li><a href="#meta-data">How do I store the meta-data (owner, group, access
mode,
+modification time) of my files in the repository?
+</a></li>
</ul>
<h4>Troubleshooting:</h4>
@@ -1889,8 +1892,25 @@
<![CDATA[=========================================================]]>
+<div class="h3" id="meta-data" title="meta-data">
+<h3>How do I store the meta-data (owner, group, access mode,
+modification time) of my files in the repository?</h3>
+
+<p>Please see the README at <a
+HREF="http://svn.collab.net/viewcvs/svn/branches/meta-data-versioning/">
+the meta-data branch</a>; for patches against 1.2.0rc2 (which apply
+against 1.2.0 with a small fuzz) see <a
+href="http://marc.theaimsgroup.com/?l=subversion-dev&m=111459962412224&w=2">
+this mail</a>.</p>
+
+<p>Please tell the developer's mailing list that you want this feature in
+the subversion distribution - currently there's no core-developer
interested.</p>
+
</div>
+<![CDATA[=========================================================]]>
+</div>
+
<div class="h2" id="troubleshooting" title="troubleshooting">
<h2>Troubleshooting:</h2>
<p/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Timestamp Frustrations/ FAQ update
Posted by ph...@bmlv.gv.at.
(cc'ed to dev@ for FAQ update)
trlists@clayst.com wrote:
> I am curious if anyone else has solved this problem. I asked about it
> many months ago and no one had.
Please see http://svn.collab.net/viewcvs/svn/branches/meta-data-versioning/ for
the branch; see
http://marc.theaimsgroup.com/?l=subversion-dev&m=111459962412224&w=2 for
patches against 1.2.0rc2 (which apply with a small fuzz also against the
released version)
As this comes up and up again, it should probably be at least listed in the FAQ
(if it isn't taken into svn itself).
Regards,
Phil
Index: faq.html
===================================================================
--- faq.html (Revision 14979)
+++ faq.html (Arbeitskopie)
@@ -122,6 +122,9 @@
on Windows?</a></li>
<li><a href="#bdb-fsfs-convert">How do I convert my repository from using BDB
to FSFS or from FSF to BDB?</a></li>
+<li><a href="#meta-data">How do I store the meta-data (owner, group, access
mode,
+modification time) of my files in the repository?
+</a></li>
</ul>
<h4>Troubleshooting:</h4>
@@ -1889,8 +1892,25 @@
<![CDATA[=========================================================]]>
+<div class="h3" id="meta-data" title="meta-data">
+<h3>How do I store the meta-data (owner, group, access mode,
+modification time) of my files in the repository?</h3>
+
+<p>Please see the README at <a
+HREF="http://svn.collab.net/viewcvs/svn/branches/meta-data-versioning/">
+the meta-data branch</a>; for patches against 1.2.0rc2 (which apply
+against 1.2.0 with a small fuzz) see <a
+href="http://marc.theaimsgroup.com/?l=subversion-dev&m=111459962412224&w=2">
+this mail</a>.</p>
+
+<p>Please tell the developer's mailing list that you want this feature in
+the subversion distribution - currently there's no core-developer
interested.</p>
+
</div>
+<![CDATA[=========================================================]]>
+</div>
+
<div class="h2" id="troubleshooting" title="troubleshooting">
<h2>Troubleshooting:</h2>
<p/>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Timestamp Frustrations
Posted by Dale Worley <dw...@pingtel.com>.
> From: trlists@clayst.com [mailto:trlists@clayst.com]
>
> I am managing (more like, attempting to manage) a single-developer web
> project with svn. The use of timestamps is embedded in my work style
> and practice in a number of ways, including simply looking at what I've
> changed lately, and routine copying of changed files between machines
> based on date.
You might want to look into the Unison file synchronizer, which copies
changed files based on their contents, which is much more robust. (It also
keeps the timestamps aligned, if you want.)
> Has there been any thought to allowing svn to preserve the file
> timestamp which reflects the normal OS meaning -- time of last
> modification to the content -- instead of time of last
> version control
> action or time of last commit? Anyone have a simple, reliable way to
> do this now?
Check through the archived mailing lists. IIRC, there's been significant
work on a Subversion option so that when Subversion updates a WC file, it
changes its modification time to be when that version of the file was
committed to the repository.
Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org