On Aug 9, 2006, at 10:14, Henk Wissink wrote:
>>> 2. Each subdirectory level in this structure represents a different
>>> software version to be maintained.
>>
>> With a version control system, these would typically be branches with
>> tags made at release points.
>
> I know. But that mechanism does not support for automatic
> propagation of a new change for all related versions. Files in
> branches/tags have some history in common but not an automatic
> common future (page 50 of the book) as I described in my reaction
> for point 1 above! That is why I ended my original request with
> "without loosing (too much) implicit and explicit relational
> information". I think that when I start using subversion, I have to
> port (page 50-52) each and every change explicitly for all versions
> that now have a common node in the directory structure and share a
> single file.
>
> Right?
Yes... that's correct...
>>> 3. Each directory level only contains those files in which it
>>> differs
>>> from its parent directory level (note the recursive nature of
>>> this!).
>>> For building purposes these files have precedence over the files
>>> with
>>> the same name/type in higher levelled directories.
>>
>> Version control systems know what is different in each version (which
>> is kind of the point...) so you don't have to do this.
>
> Correct. In our current set-up that is implemented by 'borrowing'
> missing files from the directories higher up during the building
> process.
If you already have a build system that puts together the correct
package from sources stored in the manner you've shown us, then I
don't suppose there's any reason why you can't just keep it exactly
that way in Subversion. You would have to explain the structure
clearly to anyone with write access to the repository, but Subversion
is just a (versioned) filesystem, so you can arrange the data in it
in any way that makes sense to you. "trunk, branches, tags" is just a
suggestion that you don't have to follow if it doesn't meet your needs.
> Example: date/time stamps of files seem to be different under
> subversion anyway (no matter default or by using "use-commit-times
> = yes") whereas they are now used as an essential part of the
> comparison process to find where and what should be changed. In
> case a change is implemented in some transparent way (we call it
> 'compile-time flags'), files anywhere in the directory tree that
> were the same before the change can still be kept the same
> afterwards. That costs virtually no time whereas maintenance for
> versions that need that change in the future takes less time: some
> files already have the change, it must only be effectively included
> with some compile-time configuration item from that moment on.
Right—when you commit or import, Subversion stores the current time,
not the modification time of each individual file. If you want the
latter, someone has modified Subversion to do that, but you must
build it yourself. It's called the "text-time branch":
http://svn.collab.net/repos/svn/branches/meta-data-versioning/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 9 14:06:26 2006