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
Received on Wed May 14 05:14:18 2003