Wow lots for me to process here, and I think there are a few
misunderstandings here that might be muddling things - my responses
inline, quotes heavily snipped.
On 4/30/07, Ryan Schmidt <subversion-2007b@ryandesign.com> wrote:
> I'll restate the problem as I understand it:
>
> You are trying to store XAMPP in your repository, which apparently is
> distributed as a core and then various modules. You have imported
> these as
>
> /vendors/apache-friends/xamppcore/v1.61/xampp
> /vendors/apache-friends/perl-add-on/v5.8.8.819/xampp
>
> You have copied xamppcore/v1.61/xampp to
>
> /vendors/current/xampp
>
> And the intention is that you would like to now "get all of perl-add-
> on/v5.8.8.819/xampp into current/xampp too" and "svn cp" isn't doing
> the job for you
All correct
> The way you're using "current" here is nonstandard. The standard way,
> according to the Vendor Branches chapter of the book, would be to
> have a "current" for each thing that you import or load in. As I
> explained earlier, svn_load_dirs.pl needs this. (Well, it doesn't
> need it, strictly speaking, but it's the way the documentation
> describes it.) Assuming that xamppcore and perl-add-on are two things
> that you download from some web site, then those are the levels at
> which you would have "current".
OK I see, but since I'm not using svn_load_dirs.pl, I didn't see any
reason to have a current until I realised I wanted to have a place for
all my vendor files to be working together in one place, representing
an integrated and working "everything that is not my stuff". Maybe I
should call it "combined", or perhaps I'll have reason in the future
to have subsets like "XAMPP+Perl combined", a "XAMPP+WordPress
combined" or a "XAMPP+Ruby combined", etc.
> (I'm going to call it "perl-add-on-1"
> from now on since I assume there are multiple perl add-ons that you
> might have.)
Actually no, the Perl add-on is the only one, it's what gives Perl
functionality to a XAMPP installation.
> The point of the vendor section of the repository is to track things
> that others have distributed, the way they have distributed it. If
> you want to combine these parts in some way, or modify them in other
> ways, you should do so outside of /vendors.
Well in this case the add-on is ONLY intended to give extra
functionality to the core, and it is implemented simply by (in
*nix-speak) "untar the add-on archive over the core directory".
Personally I think the resulting combination still belongs in the
vendor branch.
But in any case the fact that this:
> Now you need to "somehow" bring perl-add-on-1/5.8.8.819 into that
> trunk working copy.
is so hard for a non-programmer to do seems to be a flaw in svn to me.
Thanks for your explanations, very helpful for me.
But regarding this essential problem, my relatively low-tech
workaround (summary below) worked perfectly well:
--------------------
X=new tag "combined", initially just a copy of the core-file-superset
Y=add-on-subset
Checkout X to WC
Merge comparing X to Y (svn status - new files are "A", overwritten
files are "R", files not present in Y are "D")
Leave the "A"s and "R"s there, but revert all the "D"s with a script
Commit back to "combined", maybe copy, tag, etc.
Done
--------------------
It just takes a while for a batch file to issue an "svn revert"
command on 14000 files in 4000 folders. So until a more elegant
solution (appropriate for a Windows-using non-programmer svn noob)
comes along, I'm all set on this issue for now, but Talden's suggested
enhancement to the "svn copy" command would IMHO greatly expand
Subversion's usability in managing vendor branches.
Again, thanks for your help.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 30 19:17:49 2007