On Wed 09 Aug 2006 13:04, Ryan Schmidt wrote:
> 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...
>
You could of course use a symlink (provided your working on a Unix type
system), or svn externals.
> >>> 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
--
John Allen, mailto:john.allen@orbiscom.com
Orbiscom Ltd, http://www.orbiscom.com
Block 1,
Blackrock Business Park,
Carysfort Avenue,
Blackrock,
Co. Dublin,
Ireland.
Tel: +353-1-217.8603
Fax: +353-1-294.5119
Mobile: +353-085-1295486
Mandriva Linux release 2006.0 (Official) for i586, kernel 2.6.12-22mdk
13:23:19 up 7 days, 5:08, 2 users, load average: 0.43, 0.62, 0.51
---------------------------------------------------------------------
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:24:37 2006