[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Timestamp Frustrations

From: Roel Harbers <roel_at_roelharbers.com>
Date: 2005-06-03 16:12:42 CEST

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.


Roel Harbers

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 3 21:02:13 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.