Re: Timestamp Frustrations

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