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

Re: Best practice for my use case

From: William Nagel <bill_at_stagelogic.com>
Date: 2004-09-17 22:03:27 CEST

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel,

I'm not sure I entirely understand what problem it is that you want to
fix. You say that you think there should be a better way to work than
your current approach, but it's not clear to me what part of your
current approach you really feel is bad. I can think of a couple of
ways you might be able to change what you're doing, but I'm not sure
I'd say they're objectively better, just different. If you tell me why
you think your way is bad, though, I might be able to suggest an
improvement.

Remember, one of the strengths of Subversion is that there's no global
"right" way to do organize it. Instead, it's flexible enough that you
can tailor it to the "right" way for your individual project's
development process and workflow.

- -Bill

On Sep 17, 2004, at 2:35 PM, Daniel Khan wrote:

> Hello list,
>
> first I must say that I really enjoy working with svn.
>
> I now want to move our main projects to svn and I am not sure how to
> organize the work cycle.
> Maybe someone could give me some hints or tell me if we are on the
> right track.
>
> We have a main framework programmed in php.
> This framework contains modules.
>
> The framwork doesn't change that often.
> The modules are under heavy development and every change there should
> go into each project.
>
> A new project always consists of the framework and some modules.
> Additionally it contains parts which are only used by this project
> (images, templates,...)
>
> That's what we did:
>
> --branch
> |--project1
> | |--framework
> | |--specific_project_files
> | |--module1
> | |--module2
> |
> |- project2
> ...
> --trunk
> |--framework
> |--modules
> |--module1
> |--module2
>
>
> So everytime a new project is created we create a branch of the
> current framework.
> Then we create directories for the modules and *switch* each to the
> module directory in the trunk.
> Somehow this seems nicer to me than checking out the modules from the
> trunk into my branch.
> On irc I allready was told that :externals could solve this better.
> But that was before I figured out
> that I can switch parts of my branch to the trunk.
> I also thought of checking out from different branches into one other
> branch.
> It all stays within the same repository.
>
> Now the problems start.
> If I change the framework within project1 and I want to share it with
> the developer of project2 I do the following.
>
> - Commit the changes into my branch
> - Check out a working copy of the directory of the trunk.
> - Merge the branch version into the trunk version
> - Commit the merged version back into the trunk
> - Tell the developer of project2 that there was a change in files X,y,z
> - Dev2 now merges the trunk into his project and commits into his
> branch
>
> Somehow I think that this could be done better but I don't have a clue
> how.
> I think it makes sense to branch each project of as they contain
> specific addons which shouldn't go
> into the trunk. So using the trunk for project development isn't an
> option I think.
>
> Thanks a lot for reading all this...maybe someone could help me out...
>
> --
> Daniel Khan
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBS0MPSwe0AHUdEwQRAqJkAKDW3c/8tAMqpJLPm8JTqNy2h94vfQCgjVzD
OjP+WOfobu40ywpdu/hbI84=
=HHRy
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Sep 17 22:04:21 2004

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

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