David Faure wrote:
> On Friday 06 May 2005 02:29, Ben Collins-Sussman wrote:
>
>>On May 5, 2005, at 5:47 PM, David Faure wrote:
>>
>>
>>>Now, I want file.cc and file-in-branch.txt together in this directory.
>>
>>Sorry, not possible.
>>
>>A working copy must resemble a tree somewhere in the repository. It's
>>okay for parts of the tree to reflect disjoint sections of the
>>repository, but you cannot invent arbitrary tree-structures, "merge"
>>directory contents together, etc.
I recently started using svn and couldn't figure out how to deal with my
perceived needs - not too dissimilar to David's if I am reading right.
My approach has been to press on with it anyway and try to get a feel
for what svn can do.
Listening to you guys discussing the finer points is educational in an
eye-glazing way for me. Being Friday pm may I postulate something to see
if I actually get it?
No objections? - OK here goes.
It has been oft repeated here that a tag is a branch is a directory ...
and who cares - certainly not the software. There is no difference.
So my project A is progressing ordinarily as I add features and fix
bugs. My other three parallel projects, B, C and D which share probably
fifty percent of the code unchanged with A are just sitting there
falling further behind.
This is my plan to bring them forward with a rush ...
I'll freeze development on A, tag it as a release and ship the updated
software to the customers. Without touching the code I'll tag (or
branch) three more times to correspond with B, C and D projects.
I'll have to be a bit careful here but I'll check out the B, C and D
branches of A as working copies of projects B, C and D. As I said, being
careful I'll copy the fallen-behind B, C and D project specific files
over the top of the same-named checked out A-files (there are a number
of these). I'll have to re-do the changes to these files anyway, a merge
is out of the question. All they really share is their names so they can
be called to do different things in their different projects.
THEN, I'll svn delete the A files which I don't want in those working
copies from their respective B, C and D branches.
Penultimately, I'll (OS) copy the unique B, C and D files which I had
saved previously into their new B, C and D working copies and svn-add
them to their respective branches.
Finally in my fevered imagination I'll commit all that in three streams
to the three branches and open a bottle of red to celebrate. It is
Friday after all.
Thereafter, I'll carefully maintain four branches and tag them from time
to time as they get released.
All the common stuff (50% of the code) will be developed in the A branch
and I'll merge that into the B, C and D branches one at a time whenever
I decide to freeze project A.
Does that sound reasonable? No trunk, just four branches but one more
equal than the others.
Mike
>>That said, there's no reason we couldn't add this ability; it probably
>>wouldn't be too much of a stretch. But honestly, nobody's ever asked
>>for this feature before. What you're trying to do is rather unusual:
>>normally branches tend to have similar structures, so you just switch
>>an existing chunk of working-copy structure to reflect some analogous
>>structure on the branch. In the rare case, say, where the branch has
>>an extra directory that your working copy doesn't, you can always do an
>>extra 'svn checkout" of that directory. But you can't checkout a
>>single file, hence you're stuck.
>
>
> I don't think there's anything so "unusual" there. Branches might have
> similar directory structure, they don't necessarily have the exact same set of files.
>
> In case you're wondering why I was looking for this feature:
> it was perfectly possible with CVS. This is how we handled the development
> for a customer who wanted additional features on top of an opensource
> project's stable branch. The rules of the project forbid new features in stable
> branches, so we had to branch it. But if we branched the whole project, then
> we would have to merge manually any bugfix done in the stable branch.
> Instead, by only branching the minimum set of files that we needed to change,
> we could benefit automatically from any bugfix in the stable branch. We still
> have to manually merge fixes made to the few files we branched, but
> that's much less work.
> So with CVS we simply had a script to "switch" a set of files (and sometimes
> directories). Porting this to SVN I realize that SVN doesn't allow me to do that...
> I guess I'll branch entire directories for now, but I don't see why future versions
> of the svn client shouldn't be able to do this :)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 6 12:25:39 2005