[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: best-practice for organizing sparse/end-user-specific files in a repos?

From: William Nagel <bill_at_stagelogic.com>
Date: 2005-12-13 02:53:40 CET

Hi Richard,

> hi all,
>
> i've a question abt best-practice repos organization of sparsely-
> populated 'machine-specific'
> content.
>
> no doubt not a unique issue ... but a 1st-time occurrence for me.
>
> to explain:
>
> say i've a repos of ~ 10000 files, org'd across a hierarchy of ~250
> dirs.
>
> the repos will eventually be checked out to a number of different
> boxes.
>
> while the vast majority of the repos files are to be identical from
> machine to machine, some
> small number, say ~ 1%, contain machine-specific content ... for
> example, a machine name or an
> IP address. these files are somewhat randomly distributed across
> the repos structure.
>
>
> QUESTION:
>
> how best to organize the machine-specific files?
>
> if they were all collected in a single dir, i'd simply treat
> machine-specific data as a separate
> project/dir, labeled with a tag ... and each machine would just
> check out the 'shared' trunk,
> and its "named" dir. nbd.
>
>
> but when these machine-specific data are sparsely dispersed
> throughout the repos, how do i
> differentiate?
>
> thoughts/suggestions are much appreciated!

Well, my first suggestion would be to see if there's any way you can
reorganize your files so that the machine-specific information is all
collected in a central location. Not only will that make dealing
with version control easier, but it will also make project
maintenance easier since you won't have to worry about missing an
instance of machine-specific data when you modify the code to support
different machines.

Given that, I understand that it's not always possible to take the
best option, and refactoring your code base to better organize the
machine-specific info might not be possible. If that's the case, you
might try using symbolic links. If you're on a Unix-like platform
(i.e. anything but Windows) you can have SVN version symbolic links
for you. That way, you might be able to move all of the machine-
specific info to a separate directory and then scatter symbolic links
to those files throughout the rest of your code. Then, it would be
possible to use 'svn switch' to switch the machine-specific directory
to a tag specific to the machine(s) you want.

If you can't use symbolic links, you might consider writing a script
that would perform an 'svn switch' on each machine-specific file
individually. If you do that, though, you'll need to have
placeholder files in your main branch to perform the switches on.
You can't switch a non-existent file. For example:

svn switch http://repos/branch/machine_1/file.c ~/working_copy/trunk/
file.c

will fail if trunk/file.c doesn't exist.

Another option would be to put the different machine specific pieces
of information in the same file and use compile or runtime flags to
determine which gets used in any given instance.

-Bill

>
> thx,
>
> richard
>
>
> - --
>
> /"\
> \ / ASCII Ribbon Campaign
> X against HTML email, vCards
> / \ & micro$oft attachments
>
> [GPG] OpenMacNews at gmail dot com
> fingerprint: 50C9 1C46 2F8F DE42 2EDB D460 95F7 DDBD 3671 08C6
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (Darwin)
>
> iEYEAREDAAYFAkOdH3gACgkQlffdvTZxCMa+HQCfYDFVbeA1ELSQgQS55fmLXbN3
> +lUAmwU0HdWipTMEvcBqRNOPDQmjwgut
> =dUdK
> -----END PGP SIGNATURE-----
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Dec 13 02:59:12 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.