views:

94

answers:

5

Let's say I have working copies of several different folders from my SVN repository scattered across my file system. Their parent directories are not part of the repository. E.g.

somedir1\
   workingcopyOfA\
   workingcopyOfB\
somedir2\
   somedir3\
       workingcopyOfC\
   workingcopyOfD\

Now they all contain changes which I would like to check-in at once (calling svn only once for convenience, using only one new revision number for simplicity).

Is this possible? Is this what changelists are meant for? What can I do if I use svn < v1.5?

(There are some similar questions here on SO, but they refer to different problems.)

EDIT: To clarify: The working copies all belong to the same repository, but to different parts, i.e. the repository looks like this:

RepoDirA\
RepoDirB\
RepoDirC\
RepoDirD\
A: 

I know that Eclipse can do this but maybe they are using some tricks inside (because you can commit projects which use different repositories, too, for example one which is in CVS and the other in SVN).

I suggest to just try it with your client. If it doesn't work, it'll print an error. You can't possibly break anything.

Aaron Digulla
A: 

I think it isn't possible, not by the command-line and not with TortoiseSVN. But there could be tools that make this possible. You could write a bach-script for that also.

The changelists are something else, here you can group some changes in one workingcopy together so you can commit them seperately.

Jochen
A tool like SVN-Monitor kan help a lot, it has a feature to Update multiple working copies, but I haven't found a Commit.
Jochen
+1  A: 

It doesn't appear that you can. I tried it here, where I frequently have multiple working copies checked out. Subversion gets cranky about there being no .svn directory in the common root of the folders that you're trying to check in.

Of course, if all your working copies refer to the same repository path - that would be a really nasty thing to allow. You'd basically be expecting subversion to merge 4 sets of changes locally before putting them into the repository, which could make conflict resolution fun :)

Note that this was with subversion 1.4.5.

In 1.5 it seems that changelists are more about having multiple working sets of changes in the same working directory, and being able to treat them separately, rather than having multiple working directories and treat ing them as one entity.

D Garcia
A: 

I think that the changelist sets are maintained on a repository by repository basis - so in your example working copies A B & C would all have to be in the same repository. Then you'd have to add each of the working copies individually to the same changelist.

I can't test it (to completion) but the setup seems to work.

Gray-M
+2  A: 

As other noted, it is not possible as is for good reasons (see D Garcia's answer notably).

If eclipse supports something like it, I suspect it creates multiple checkins behind your back.

What is possible however is to diff the changes in one working directory and apply those changes to the other working directory (if they overlap). Once you've done that, all your changes are in the single working directory where you can check in from. The merging issues D Garcia pointed at are now your responsibility to resolve at patch time.

If your working directories don't overlap, and the only reason you have multiple working directories is because e.g. you did not want to pull the whole repository, I suggest checking out the hierarchy to the common root of your working directories, but non-recursively (using svn co -N root) and then get the specific working directories with svn update path/to/subsetOfInterest for the intermediate directories). That way, they all live inside the same working directory, and allow to work on them atomically.

Bahbar