Re: Timestamp Issues

Before we get to the meat, I don't know if you saw this in the client
config (note client, not server) or not [~/.subversion/config]:

   ### Set use-commit-times to make checkout/update/switch/revert
   ### put last-committed timestamps on every file touched.
   # use-commit-times = yes

May be useful for you to lock last changed timestamp to commit times.

On Mon, 2004-29-11 at 21:55 -0500, trlists@clayst.com wrote:
> On 29 Nov 2004 Christopher Ness wrote:
> > Do you _have_ to use that tool or can you do some scripting in SVN to
> > deploy changes into production?
>
> Well yes, but I'd rather not! I'm also used to simply observing the
> timestamps (as in "well, I probably don't have to check there to see if
> that's where the newly created problem is, because that file hasn't
> changed since last July"). I shouldn't be reworking my whole work
> environment to meet the needs of the VCS -- it should be a tool, not a
> framework that defines the development setup (though these days, many
> of the tools behave like wannbe frameworks! :-)).

I like simple things too, I like them a lot! But now that I'm a little
more comfortable with subversion and *nix, these things are becoming
more trivial to pin down.

To comment on your example above about someone breaking the build:

For example if someone committed a file that broke something in the past
- lets say day - on the subversion server you just need to ask for the
logs for those times. You can do this example for yourself by checking
out the trunk of the SVN project.

Of course you could use this method to find all the changed files in
July, but there could likely be duplicates, use `sort` and `uniq` to get
rid of those.

WARNING: Someone may have a better method of discovering the files that
changed between two time periods. Please speak up as I'd like to know
too! Windows users can get a GNU/bash environment apparently.

[nesscg@woman trunk]$ svn info Path: .
URL: http://svn.collab.net/repos/svn/trunk
Repository UUID: 65390229-12b7-0310-b90b-f21a5aa7ec8e
Revision: 12092

<snip> Below might be interesting to you</snip>

Last Changed Date: 2004-11-29 20:56:04 -0500 (Mon, 29 Nov 2004)
Properties Last Updated: 2004-09-15 13:26:31 -0400 (Wed, 15 Sep 2004)

[nesscg@woman trunk]$ svn diff -r{2004-11-28}:{"2004-11-29 22:30"} |
grep "^Index"
Index: build.conf
Index: www/project_links.html
Index: notes/fs_dumprestore.txt
Index: subversion/include/svn_ctype.h
Index: subversion/include/svn_utf.h

<snip> More file paths are output here </snip>

Index: doc/translations/spanish/book/ch04.xml
Index: doc/translations/spanish/glosario_traduccion
Index: doc/book/TODO
[nesscg@woman trunk]$

Now you have a hitlist to look through for the buggy code. Some you can
probably ignore right away. For example if the problem wasn't in the
book source.

> The FTP client isn't a "middle man" it's a tool appropriate for the
> job. One of the things I like about Subversion is that it doesn't try
> to be something more than a VCS -- but I wish (based on admittedly very
> limited experience) that it didn't make quite so many assumptions about
> how VCS users operate. Of course it has to make some -- I just want
> the ones that don't work for *me* left out :-).

Now you need to get the changed files onto the production server. I'm
going to leave that as a exercise for the reader as there are many ways
of doing that task.

As an aside:

I find SVN is very much a Unix based product in that you should be able
to take the output from it and pipe it into another program to get some
work done. I like that ability.

Have fun!
Chris