On Sep 18, 5:20 pm, "Marcio E. Kaneko" <mkan..._at_usp.br> wrote:
> We utilize Tortoise SVN in a 40 people group divided in 5 major areas.
>
> Now say someone from area B try to create the same object in a different
> folder unnecessarily.
>
Aren't you assuming that the copy is unnecessary in the first place?
Sometimes you copy something because you want to modify it somewhat.
Maybe area B's purposes is functionally a bit different than that for
area A.
> How can I avoid this?
>
Presumably 'this' means copying without modifying anything and area B
is trying to use exactly the same thing as area A and they will always
(for the forseeable future at least) always want to stay in sync.
In that situation,
- Consider using the svn_external property. Read up on it from the
Subversion manual and see if it meets your needs. If so, talk to the
area B folks about using it.
- Be wary about whether you use or don't use a specific revision
number on the svn_external. There are plusses and minuses to
specifying a particular revision number. Also look into whether or
not using the Perl script svncopy.pl might fit your needs when it
comes to archiving builds that use svn_externals that don't (or might
not) specify specific revision numbers.
> I mean, there are any way to warn area B that area A has the same stored
> procedure versioned on the repository and ask for confirmation before
> duplicating it?
>
If someone is copying it, they are doing it explicitly. The copy is
not something going on in the background so a warning would just be
nagging.
The bigger issue to what you're talking about though has nothing to do
with the tool. What you're trying to implement is a reusable code
repository where developers can dip into and pull out pieces that they
need. There are plusses and minuses to that also but trying to use
any tool to try to legislate that methodology is doomed to fail.
Either your developers understand the advantages, disadvantages and
other implications of a shared code base or they don't. If they
don't, then you first have to clear the hurdle of getting to a design
process that encourages code reuse in the first place.
Whether or not that is achievable is likely a design culture type of
thing with your organization. If your area B folks generally copy,
then this suggests that a common code base is perhaps not too high on
the priority list for the area B folks...just a guess. If your
organization does value (or wants to value) code reuse then
svn_external (possibly aided by svncopy.pl) is the likely ticket for
your group when using Subversion.
Kevin Jennings
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2396666
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-09-19 07:46:07 CEST