Repeatability Files

[Jonathan Smith <jo...@members.limitless.org>]

In our project, we test the output's repeatability from each change to the 
next.  The ouput consists of maybe 10 meg.  In order to facilitate 
conflict resolution, I need to have these files available for the most 
recent version of the code to compare my version with the conflicts 
resolved against.  As this output *can* be generated from the compiled 
version of the code in the repository, this output, strictly speaking, 
shouldn't be revision controlled.

For example:
repository has version n
I checkout version n
Harry commits version n+1
My change is repeatable
I update to version n+1 with my changes
I need the output of version n+1 to compare to, I only have version n
Recompiling version n+1 without my changes is virtually impossible without 
	a second checkout of the sourcecode.

My thought is, fine.  Just commit the output files...  store them in a 
separate top level directory that can be disregarded; however, link them 
in where they belong in the repository.  I don't remember what this is 
called, possibly externals, but I remember reading about it in the 
documentation.  But, thats about 20 lines of change simply by re-running 
the program (time-date stamps) and hundreds of thousands if we actually 
change the output.  Can we reduce this with a meta data tag to specify to 
only hold N revisions in history?  I'd be agreeable to N=1, though i'd 
prefer N=5 or N=10.

I'm sure that this is far, far, far easier than my last request.

I'm *really* starting to like the meta data.  Power to the users!

j.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org