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

Re: Two more questions about "mix-and-match" working copy.

From: Kevin Hung <cykhung_at_gmail.com>
Date: 2006-02-14 19:42:37 CET

Hi Jody,

Thanks for your reply. Sorry that I did not make it clear on what I want to
do in my first posting. So here it goes.

I am very happy with TSVN as source control and so I can easily share code
with my co-workers. But sometimes I have codes (or files) that are just for
my own use and so I don't want to add those files into the trunk (don't want
to pollute the trunk). But on the other hand, I also want TSVN to protect
and keep track of those files (again for my own use). So I think branching
with mix-and-match directories are useful for that. But after a weekend of
trying out different use-case scenarios with TSVN, my conclusion is that
TSVN (or SVN) is not really designed for something like that. Actually
branching is almost what I need. The only problem that I run into is that
SVN does not keep track of merging changes from trunk to branch (and vice
versa). I have to make sure that I don't apply the merging more than once.
In some complicated use-case, this is not simple to do manually.

At the end, I come up with a relatively simple procedures using branching
and mix-and-match directories to do what I want. Note that the usual
branching is difficult for me to use since for 90% of the files pointing to
the trunk, I want to be able to use those simple commands (eg. Update / Show
Modifications) for these files. My procedures are not fool-proof but it is
good enough. I restrict myself to only use "svn merge" to bring changes from
trunk to branch and never use "svn merge" to bring changes from branch to
trunk.

If you are interested, let me know and I will post it in this thread.

On 2/13/06, Jody Shumaker <jody.shumaker@gmail.com> wrote:
>
> On 2/11/06, Kevin Hung <cykhung@gmail.com> wrote:
> > Hi everyone,
> >
> > I am learning about "mix-and-match" working copy in TSVN (i.e. some
> files
> > point to the trunk and some files point to a branch).
> >
> > Question 1
> > ----------------
> > The repository already has a trunk and a branch for my project.
> >
> > Step 1: I do a checkout from the trunk and so now I have a working copy
> > with all files and directories pointing to the trunk.
> >
> > Step 2: I also do a checkout from the branch and so now I have another
> > working copy with all files and directories pointing to the branch.
> >
> > Step 3: In the branch working copy, I create a file (let's call it
> foo.c)
> > and add/commit to the branch.
> >
> > Step 4: Now in the trunk working copy, I would like to have a local
> copy of
> > the file foo.c and this file should point to the branch. Bascially this
> file
> > is for my own use (for now) and I don't want it to show up in the trunk.
> Is
> > this possible?
> >
> >
>
> It was my understanding that this is currently not possible. I thought
> Subversion requires there to be one url for the current folder and
> thus all files in it will only be based on that repository url.
> However based on your below post, it seems that you point out that
> mix-matched working copies are possible. I can't think of any way of
> getting the one single file over from the branch into the trunk
> working directory that would continue to have it updated etc.
>
> > Question 2
> > ----------------
> > This question is about "Update" and "Check for Modifications". The
> > repository already has a trunk and a branch for my project.
> >
> > Step 1: I do a checkout from the trunk and so now I have a working copy
> > with all files and directories pointing to the trunk.
> >
> > Step 2: I also do a checkout from the branch and so now I have another
> > working copy with all files and directories pointing to the branch.
> >
> > Step 3: In the trunk working copy, I "switch" a file to point to the
> > branch. Note that both the trunk and branch have the same file with
> > identical revision. So now my working copy becomes a mix-and-match.
> >
> > Step 4: For a reason, I delete the file in the branch (in the
> Repository
> > Browser).
> >
> > Step 5: I do a "Update" on the mix-and-match working copy (top-level
> > directory) and the file is deleted. This kind of makes sense. But then
> the
> > problem is that when I do "Check for Modifications" on the top-level
> > directory of my mix-and-match working copy, TSVN said that there is no
> > difference but actually there is a difference : the trunk working copy
> has
> > foo.c but my working copy does not.
>
> This seems to make perfect sense to me, you've told it to follow the
> branch as far as that file is concerned and in the branch that file is
> destroyed. You think there is a difference, but based on how you've
> told svn to behave there isn't. It seems to me that doing this puts
> the working copy in a bad state as it is now impossible to switch the
> deleted file back, though maybe a command line command could still do
> it. I'd suggest switching the file back from branch to trunk before
> deleting it from trunk, or heck change your practices so you're never
> doing this.
>
> >
> > This kind of points to the fact that after I make my working copy to be
> > mix-and-match, I cannot trust Update nor "Check for Modifications" to
> > actually see or synchronize my working copy with the trunk.
> >
>
> You can trust it to do what you've told it. I have to ask why you are
> dealing with such a mix-matched working copy as the whole idea seems
> to contradict the point of branches. I would believe has to be some
> better way that wouldn't cause the 2 situations you described to ever
> even occur.
>
> - Jody
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
> For additional commands, e-mail: users-help@tortoisesvn.tigris.org
>
>
Received on Tue Feb 14 19:42:58 2006

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

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