On Tue, Apr 7, 2009 at 21:13, Andrey Repin <anrdaemon_at_freemail.ru> wrote:
> Greetings, Andy Levy!
>
>>>> We have a single repository which has multiple projects.
>>>> every project has "tags" folders.
>>>
>>> And you've indeed noticed that every commit to one of these projects increase
>>> revision number for all of them?
>>> If they are completely separate projects, you better split them and host every
>>> project separately.
>
>> There really is no need to do that unless every project is required to
>> have its own contiguous set of revision numbers. This is most often
>> done by people/organizations placing too much emphasis on the actual
>> value of the number, instead of using it to refer to a specific point
>> in time.
>
>> We keep all our code in a single repository and no one has raised an eyebrow.
>
> I see what you mean.
> I just discovered it myself.
>
> User a committing file c
> User b committing file d
> User a updating his working copy
> User b removing file d
> User a committing file e referencing d
> -------
> Project destroyed.
>
> I know, it's not a big deal for SVN. I know how to fix it.
> It's not a bugreport. It's just a thing for consideration.
> At the very least, it leading to the moment of frustration.
> Here you have working copy that you just committed to repository, and here you
> update your working copy and it does not work.
>
> SVN does not notify you that you're likely to run in such situation while
> doing commit from outdated BASE.
Does any other VCS prevent this from happening without locking the
entire project?
What you illustrate is a team communication deficiency, not a
Subversion deficiency. No software can fix that.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1587622
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-08 03:33:39 CEST