On Mar 24, 2006, at 2:35 PM, Jay Lessik wrote:
> -- SNIP --
>
> The thing to be aware of is that, at least until SVN
>> supports true renames, reorganizing your repository
> is
> painful--anyone
>> who has checked out your code may need to delete
> their working copies
>> and re-checkout, especially if they've been working
> on a moved file.
>
> They won't have to delete their working copies, they
> can just use svn
> switch to point to the new location.
>
> And I don't believe that supporting true renames will
> make the re-org
> any less or more painful, the developers will still
> need to switch
> their working copies over to the new location.
>
> -- SNIP --
>
> That brings up an interesting question... Right now
> our repository doesn't have any trunk, branch, or tag
> directories... just a bunch of projects... I assumed
> that I could just create the trunk, branch, and tag
> directories under each project, then use svn move (I
> use tortoisesvn) to move the files from the root of
> the project into the trunk directory... But what
> happens if some developers have the code checked out
> and have modifications on their local machines? If
> they point to the new location (project/trunk) then it
> should commit properly, right? Since the path is the
> same relative to trunk?
Yes. If you have your developers do an "svn switch" to the new
location, it will work the same as doing an "svn update" on the
working copy. Any differences between the old location and new
location (which in your case should actually be none) will be applied
to the working copies, and conflicts will be handles normally, and
any local changes will remain intact. Then, next time a commit is
performed the commit will go to the new location.
-Bill
>
> Thanks for all the help, I really appreciate it...
>
>
>
> --- Blair Zajac <blair@orcaware.com> wrote:
>
>>
>> On Mar 24, 2006, at 8:33 AM, Gale, David wrote:
>>
>>> Jay Lessik wrote:
>>>> I'm new to subversion so forgive me if this
>> question
>>>> is newbie-ish...
>>>>
>>>> I know that project repository structure has been
>>>> discussed on this list and I've read a lot of the
>>>> posts, but I wasn't able to find a clear answer
>> to the
>>>> question of which of the following is better?
>>>>
>>>> repository/
>>>> projectA/
>>>> trunk/
>>>> branches/
>>>> tags/
>>>> projectB/
>>>> trunk/
>>>> branches/
>>>> tags/
>>>>
>>>> OR...
>>>>
>>>> repository/
>>>> trunk/
>>>> projectA/
>>>> projectB/
>>>> branches/
>>>> projectA/
>>>> projectB/
>>>> tags/
>>>> projectA/
>>>> projectB/
>>>>
>>>> The documentation recommends the first structure
>> as do
>>>> a lot of other sites and people on this list, but
>> this
>>>> post
>>>>
>>
> (http://svn.haxx.se/users/archive-2005-04/1870.shtml)
>>>> seems to recommend the second structure and lists
>> some
>>>> good reasons... Would using the second structure
>>>> cause problems down the road? I don't want to
>> have to
>>>> reorganize my repository later when I find out I
>> can't
>>>> do something or something isn't working
>> properly...
>>>
>>> They both work, and both allow (roughly) the same
>> reorganization
>>> possibilities. The thing to be aware of is that,
>> at least until SVN
>>> supports true renames, reorganizing your
>> repository is painful--anyone
>>> who has checked out your code may need to delete
>> their working copies
>>> and re-checkout, especially if they've been
>> working on a moved file.
>>
>> They won't have to delete their working copies, they
>> can just use svn
>> switch to point to the new location.
>>
>> And I don't believe that supporting true renames
>> will make the re-org
>> any less or more painful, the developers will still
>> need to switch
>> their working copies over to the new location.
>>
>>>
>>> Personally, I'd examine how closely ProjectA and
>> ProjectB are related;
>>> if they're not at all, consider setting up two
>> repositories (one for
>>> each). Short of that, I'd tend to go with the
>> second repository model
>>> (repos/{trunk/tags/branches}/{project...}), as
>> that's clearer to me,
>>> though the distinction is small; one of the few
>> instances where it'll
>>> come up is checkouts:
>>>
>>> svn co <repos>/trunk/projA
>>> ...creates a directory named "projA", whereas
>>> svn co <repos>/projA/trunk
>>> ...creates a directory named "trunk", which is
>> hardly helpful.
>>> Especially since you can then switch it to a
>> branch directory, and
>>> confuse everyone. Of course, you can get around
>> this by always
>>> explicitly setting a directory name, but why
>> bother?
>>
>> That's just a naming issue. One many of the
>> projects I work on, we
>> have per-user branches and a trunk where users merge
>> their work
>> into. So you end up having a directory containing
>> working copies
>> named like this:
>>
>> $ ls
>> projecta-branch
>> projecta-trunk
>> projectb-branch
>> projectb-trunk
>>
>> Here it's implied that the branch is my per-user
>> branch.
>>
>> So you'll have to specify the directory to check out
>> into anyway.
>>
>> So I still recommend that you have the
>> project/{trunk,tags,branches}
>> structure.
>>
>> Regards,
>> Blair
>>
>> --
>> Blair Zajac, Ph.D.
>> <blair@orcaware.com>
>> Subversion training, consulting and support
>> http://www.orcaware.com/svn/
>>
>>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> 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 Sat Mar 25 19:45:44 2006