You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Brad Schick <sc...@hotmail.com> on 2004/12/10 06:45:49 UTC
svn log questions
I think svn log -rPREV has a surprising behavior. -rPREV seems to look
for literally COMMITTED-1, which often doesn't exist for a specific item.
Wouldn't this be more useful if it looked for the previous *change* on an
item so that "svn log -rPREV file" showed the log for the prev change?
I also find it odd how log works with file globs. Something like "svn
log -rCOMMITTED *.cpp" produces an error and even "svn log *.cpp" doesn't
do what I would expect (a list of files with the log for each). Am I
thinking about this wrong? How would I get a quick list of the last
commit log for each file in a directory?
-Brad
---------------------------------------------------------------------
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 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 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
Timestamp Frustrations
Posted by tr...@clayst.com.
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: svn log questions
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
On Fri 2004-12-10 at 08:46:52 +0000, you wrote
> >I think what you want is 'svn log file --limit 1'. It will stop after
> >showing you one log message, and that's guaranteed to be the most recent
> >change on a file.
>
> What I really wanted was the second entry in 'svn log file --limit 2'
> without having to search for the second entry (i.e. what I thought
> -rPREV would do)
I didn't see anyone else mention it, so I'll do. You can get the
behaviour you want by excluding the first revision. And you already
know how to get there, by -rPREV. So I think the following should do
what you asked for:
svn log -r PREV:1 --limit 1 file
(That's just a untested projection, because my version of svn doesn't
support --limit).
Bye,
Benjamin.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log questions
Posted by François Beausoleil <fb...@ftml.net>.
On 10/12/2004 12:05, trlists@clayst.com wrote:
> What switch (if there is one) means "run the subcommand on a default
> target of CWD at the most recent revision which has a committed change
> to CWD"?
svn log -rhead:1 .
> What exactly is getting updated when you do an svn update and nothing
> has actually changed except the single file you just committed? Is it
> just the revision number in .svn/entries?
Yup!
Bye,
François
Re: svn log questions
Posted by tr...@clayst.com.
On 10 Dec 2004 Ben Collins-Sussman wrote:
> After the commit is done, your working copy of foo.c is at r6, but the
> entire rest of your working copy (including the parent dir of foo.c) is
> still at r5. (Most people don't realize that after *every* commit,
> they have a mixed-revision working copy!)
Good point. I sure didn't!
I think the docs are confusing on this. The section on "The
Limitations of Mixed Revisions", which I had read a couple of times,
makes it sound like it's a bit out of the ordinary to have mixed
revisions. It may be odd in the world of VCS's generally, but for
Subversion it is probably the normal state of a WC and that would be
worth mentioning. It is described as a "special flexibilty" and not as
the routine condition.
> When you run 'svn subcommand' with no arguments, it means, "run the
> subcommand on a default target of CWD at its working revision". This
> is the general rule.
The issue then is the definition of "working revision". I would have
called the "working revision" r6 in your example, but I see it can be
defined either way.
What switch (if there is one) means "run the subcommand on a default
target of CWD at the most recent revision which has a committed change
to CWD"?
What exactly is getting updated when you do an svn update and nothing
has actually changed except the single file you just committed? Is it
just the revision number in .svn/entries?
Thanks,
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log questions
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 10, 2004, at 9:31 AM, trlists@clayst.com wrote:
> On 10 Dec 2004 Ben Collins-Sussman wrote:
>
>> Another example of this is:
>>
>> svn commit foo.c
>> svn log
>>
>> You'd think that 'svn log' would show you the commit to foo.c that you
>> just made, right? After all, that's what CVS does. But it doesn't...
>> not without running 'svn up' first. It's been the subject of much
>> debate, but it's another example of 'consistency' winning out over 'do
>> what I mean'.
>
> I'll give you that last point :-).
>
> Anyway, the item above bit me a couple of times. Why is this? What is
> svn up doing that makes the log show the commit?
>
Suppose you have a working copy, all at revision 5. You edit foo.c and
commit it, creating revision 6.
After the commit is done, your working copy of foo.c is at r6, but the
entire rest of your working copy (including the parent dir of foo.c) is
still at r5. (Most people don't realize that after *every* commit,
they have a mixed-revision working copy!)
When you run 'svn subcommand' with no arguments, it means, "run the
subcommand on a default target of CWD at its working revision". This
is the general rule.
So, immediately after you do your commit, an 'svn log' command is
actually the same as running 'svn log .@5'. In other words, "show me
all changes that ever happened within parent_dir, starting at r5, and
going backwards." And that means, of course, that r6 never shows up in
the output.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log questions
Posted by François Beausoleil <fb...@ftml.net>.
On 10/12/2004 10:31, trlists@clayst.com wrote:
> On 10 Dec 2004 Ben Collins-Sussman wrote:
>> svn commit foo.c
>> svn log
>>
>>You'd think that 'svn log' would show you the commit to foo.c that you
>>just made, right? After all, that's what CVS does. But it doesn't...
>>not without running 'svn up' first. It's been the subject of much
>>debate, but it's another example of 'consistency' winning out over 'do
>>what I mean'.
>
> I'll give you that last point :-).
>
> Anyway, the item above bit me a couple of times. Why is this? What is
> svn up doing that makes the log show the commit?
See "The Limitations of Mixed Revisions" in the Subversion book:
http://svnbook.red-bean.com/en/1.0/ch02s03.html#svn-ch-2-sect-3.4
Hope that helps,
François
Re: svn log questions
Posted by tr...@clayst.com.
On 10 Dec 2004 Ben Collins-Sussman wrote:
> Another example of this is:
>
> svn commit foo.c
> svn log
>
> You'd think that 'svn log' would show you the commit to foo.c that you
> just made, right? After all, that's what CVS does. But it doesn't...
> not without running 'svn up' first. It's been the subject of much
> debate, but it's another example of 'consistency' winning out over 'do
> what I mean'.
I'll give you that last point :-).
Anyway, the item above bit me a couple of times. Why is this? What is
svn up doing that makes the log show the commit?
Thanks,
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log questions
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 10, 2004, at 3:08 PM, Bradley Schick wrote:
>> The reason we defined PREV == COMMITTED-1 is because it saves network
>> round-trips.
>
> Ah, at least I undestand the tradeoff now.
>
>> But maybe in svn 2.0 we could switch to your definition instead.
>> Maybe it's worth the extra traffic...?
>
> When commands use -rPREV I'd assume some server communication
> is always required to complete it??
Well, no server communication is required to convert the string 'PREV'
into an actual number. We just grab the 'last-changed-revision' field
from .svn/entries, and then subtract 1.
Then, later on, we probably use that number when talking to the
repository. But there's no need to ask the repository for
history-tracing.
> If that is true, then I'd think adding
> one more round-trip might be acceptable. But if the proposed change
> to PREV would introduce server communication where there was
> previously none, then it might be more of a problem.
>
> Anyway, thanks for all your time on this. Should I file a feature
> request for 2.0?
>
Sure, file an 'enhancement' request, but in 'unscheduled' milestone...
so we remember to discuss it on the dev@ list later on.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log questions
Posted by Bradley Schick <sc...@hotmail.com>.
> The reason we defined PREV == COMMITTED-1 is because it saves network
>round-trips.
Ah, at least I undestand the tradeoff now.
>But maybe in svn 2.0 we could switch to your definition instead. Maybe
>it's worth the extra traffic...?
When commands use -rPREV I'd assume some server communication
is always required to complete it?? If that is true, then I'd think adding
one more round-trip might be acceptable. But if the proposed change
to PREV would introduce server communication where there was
previously none, then it might be more of a problem.
Anyway, thanks for all your time on this. Should I file a feature
request for 2.0?
-Brad
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log questions
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 10, 2004, at 1:54 PM, Bradley Schick wrote:
>>> I still wonder why making -rPREV be the previous change revision
>>> wouldn't be a better solution.
>>
>> There's a design tension between these goals:
>>
>> - "optimize every command to behave differently, so that each
>> command can guess what the user really means", and
>>
>> - "define a bunch of concepts, and make them behave consistently
>> across all commands"
>>
>> You can't have it both ways, and the svn developers chose to go for
>> the latter goal.
>
> I was not suggesting special behavior for log. What I meant was; why
> not make -rPREV be mean "last changed revision" for all commands?
> When I say this:
>
>>> Since as you pointed out a file could not have changed
>>> between "COMMITTED-1" and the previous change revision, commands
>>> like diff would not be effected while log would work better.
>
> I mean: Wouldn't a different consistent behavior actually work better?
You and I have different definitions of "last changed revision". In my
r5, r10, r20 example, if COMMITTED == 20, then you want PREV to mean
15. But throughout all the subcommands, we've defined PREV to mean 19,
because the *contents* are guaranteed to be the same as r15. It just
so happens that this definition works well for all the commands but
'svn log', where the result isn't so intuitive.
The reason we defined PREV == COMMITTED-1 is because it saves network
round-trips. To get from r20 to r15, we'd have to ask the server to do
some history tracing and report the results. But maybe in svn 2.0 we
could switch to your definition instead. Maybe it's worth the extra
traffic...?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log questions
Posted by Bradley Schick <sc...@hotmail.com>.
>> I still wonder why making -rPREV be the previous change revision wouldn't
>>be a better solution.
>
>There's a design tension between these goals:
>
> - "optimize every command to behave differently, so that each command
>can guess what the user really means", and
>
> - "define a bunch of concepts, and make them behave consistently across
>all commands"
>
>You can't have it both ways, and the svn developers chose to go for the
>latter goal.
I was not suggesting special behavior for log. What I meant was; why
not make -rPREV be mean "last changed revision" for all commands?
When I say this:
>>Since as you pointed out a file could not have changed
>>between "COMMITTED-1" and the previous change revision, commands
>>like diff would not be effected while log would work better.
I mean: Wouldn't a different consistent behavior actually work better?
-Brad
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log questions
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 10, 2004, at 2:46 AM, Bradley Schick wrote:
>
> I still wonder why making -rPREV be the previous change revision
> wouldn't
> be a better solution.
There's a design tension between these goals:
- "optimize every command to behave differently, so that each command
can guess what the user really means", and
- "define a bunch of concepts, and make them behave consistently
across all commands"
You can't have it both ways, and the svn developers chose to go for the
latter goal.
Another example of this is:
svn commit foo.c
svn log
You'd think that 'svn log' would show you the commit to foo.c that you
just made, right? After all, that's what CVS does. But it doesn't...
not without running 'svn up' first. It's been the subject of much
debate, but it's another example of 'consistency' winning out over 'do
what I mean'.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log questions
Posted by Bradley Schick <sc...@hotmail.com>.
Thanks for all the info.
>>Wouldn't this be more useful if it looked for the previous *change* on an
>>item so that "svn log -rPREV file" showed the log for the prev change?
>
>I think what you want is 'svn log file --limit 1'. It will stop after
>showing you one log message, and that's guaranteed to be the most recent
>change on a file.
What I really wanted was the second entry in 'svn log file --limit 2'
without
having to search for the second entry (i.e. what I thought -rPREV would do)
I still wonder why making -rPREV be the previous change revision wouldn't
be a better solution. Since as you pointed out a file could not have changed
between "COMMITTED-1" and the previous change revision, commands like
diff would not be effected while log would work better.
In other words, isn't the last changed revision also "guaranteed to be the
version of the file just before the latest version"?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log questions
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 10, 2004, at 12:45 AM, Brad Schick wrote:
> I think svn log -rPREV has a surprising behavior. -rPREV seems to look
> for literally COMMITTED-1,
It's not surprising: it's consistent across all commands. "COMMITTED"
of a file is defined to be the last revision in which the file changed,
effectively equivalent to the per-file revision. "PREV" is defined to
be "COMMITTED-1", just as you said. In file terms, COMMITTED-1 is
guaranteed to be "the version of the file just before the latest
version".
> which often doesn't exist for a specific item.
PREV *does* exist for each file, but the problem here is that it's not
likely that the file was part of a commit in rPREV.
For example, suppose a file changed in r10, r15, and r20. You check
out r20 into a working copy. COMMITTED of the file is r20, and PREV is
r19. If you were to run 'svn cat -rPREV', you'd get r19 of the file,
which happens to be identical to r15, r16, r17, and r18. They're all
the same "previous version" of the file.
Unfortunately, this doesn't mesh with 'svn log' semantics quite so
well. 'svn log -rX[:Y] PATH' is like asking for the intersection of
two searches: the intersection of all log messages within the -rX:Y
range, and the intersection of all commits which affected PATH. If
PATH was never changed within the -rX:Y range, then the result is no
intersection: the empty set. That's why you see nothing.
> Wouldn't this be more useful if it looked for the previous *change* on
> an
> item so that "svn log -rPREV file" showed the log for the prev change?
If you leave off the revision search range, then 'svn log PATH' shows
all commits that ever affected PATH.
I think what you want is 'svn log file --limit 1'. It will stop after
showing you one log message, and that's guaranteed to be the most
recent change on a file.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: svn log questions
Posted by Dale Worley <dw...@pingtel.com>.
Are you sure about that point? I just tried "svn log *" and it did give me
"svn log" for each file in the directory that was under change control.
Dale
-----Original Message-----
From: Brad Schick [mailto:schickb@hotmail.com]
I also find it odd how log works with file globs. Something like "svn
log -rCOMMITTED *.cpp" produces an error and even "svn log *.cpp" doesn't
do what I would expect (a list of files with the log for each). Am I
thinking about this wrong? How would I get a quick list of the last
commit log for each file in a directory?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org