> - 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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Jun 3 21:02:13 2005