Duncan Booth wrote:
> Sadly things aren't quite that black-and-white. If you use Subversion to
> store binary files, such as word processor documents, then they can't be
You can merge Word files. Word provides this option under Tools >
Compare and merge documents (don't know the exact wording, because it's
"Extras > Dokumente vergleichen und zusammenführen" for me).
There are also tools starting Word directly as diff tool for two files
(specify them in the TSVN settings for *.doc).
But you're right the diff capabilities are limited and even not
available for most binary files. I just wanted to show you that Word
files are not a good example :-)
> In this case it sounds like the requirement isn't actually for locking,
> just for knowing which files are being worked on. It may be that a better
> scheme to handle this situation would simply be to ensure that all
> development is done on branches (remember branches are cheap to create),
> and checkins are done very frequently.
> So before developer A starts working on issue #666 they create a
> branch/issue-A-666 and make sure they do a checkin every time the unit
> tests pass (e.g. every 10 minutes). Nobody else works on the same branch,
> so you can see which files are being worked on by just looking at the
> branch. When the developer has completed their work you then merge back to
> the trunk. For this to work you may have to reeducate developers (I've
> known some people not check work in for weeks at a time), but it lets you
> track where the work is happening without impacting on separate
Hm, I think you can even see the split off from trunk/ in the Revision
> Another option might be for them to handle the issue entirely outside
> Subversion: set up a background process to periodically run 'svn status'
> over all of a developer's working copies and post the output files to a web
> server which can process them and produce a report (or if the project
> involves a makefile simply get the build step to do the 'svn status').
Does not sound bad but requires a lot of work, I think...
Molle's idee with a own property sounds good to me. That can be parsed
by the script on the repository only and create a status page like you
suggested. So the script has to run only on one machine and the WCs are
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Mar 23 12:18:58 2005