You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Karan, Cem (Civ, ARL/CISD)" <CK...@arl.army.mil> on 2004/11/04 19:34:24 UTC

Same code in multiple repositories? (was: Re: svncopy)

> -----Original Message-----
> From: Peter Valdemar Mørch [mailto:swp5jhu02@sneakemail.com] 
> Sent: Thursday, November 04, 2004 11:49 AM
> To: Dale Worley dworley-at-pingtel.com |Lists|; Subversion Users
> Subject: Re: svncopy
> 
> 
> Dale Worley dworley-at-pingtel.com |Lists| wrote:
> > I am working on updating svncopy so that it can branch/tag several 
> > trees from several repositories at a time.
> 
> I'm just curious: Sounds like the code in these different 
> repositories 
> are related. Why are they in separate repositories? Are there any 
> advantages to having them split up?
> 
> (I realize you weren't really asking for someone to question 
> your basic 
> premise, but hey, that's what _I'm_ curious about, sorry... :-D)
> 
> Peter
> -- 
> Peter Valdemar Mørch
> http://www.morch.com

Just an idle question; is it possible to check-in the same code into multiple different repositories?  E.g. set up repositories A, B, and C, then check in the same code into each repository AND have all of the 'svn' commands update EACH repository?

The reason I'm thinking about this is for 'libraries'; not real libraries, but those code bases that seem to find their way into everything, but that you never quite seem to bother turning into a real library.  I've got some lying around that, if changed, may break several older projects.  Unfortunately, I tend to change them on a regular basis (like when I find a feature is actually a bug).  Ideally, I could create working repositories for each of those projects that include the library code.  If I change the code, then when I do a commit on the library, it just makes a new revision for those projects.  If I break something, then I can roll back to an earlier version of the project.

I know that many of you might tell me to make that code a real library, and to put it in its own repository, but then I need to keep track of which revision of the code worked with a particular revision of each project; that's not ideal, and I'd rather go with the option above.

Alternatively, I could create a single repository and stick ALL of my code in there, but it feels cleaner to me to have different repositories for different projects (also makes the repositories small enough that I can burn CD backups; putting ALL of the code + resources in one repository would be painful to backup)

Thanks,
Cem Karan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org


RE: Same code in multiple repositories? (was: Re: svncopy)

Posted by Dale Worley <dw...@pingtel.com>.
I think a better way to do this is to use externals.  Each project that uses
the library contains an external reference to the library (which may be
elsewhere in the same repository, or in a different repository).  As long as
the project works with the current version of the library, the project
automatically inherits the latest library.

If the project can't work with the library HEAD, you can edit the external
reference to pin it to a particular revision of the library.  Eventually,
when you get things worked out, you can remove the revision specification on
the external reference.

Dale

-----Original Message-----
From: Karan, Cem (Civ, ARL/CISD) [mailto:CKaran@arl.army.mil]

The reason I'm thinking about this is for 'libraries'; not real libraries,
but those code bases that seem to find their way into everything, but that
you never quite seem to bother turning into a real library.  I've got some
lying around that, if changed, may break several older projects.
Unfortunately, I tend to change them on a regular basis (like when I find a
feature is actually a bug).  Ideally, I could create working repositories
for each of those projects that include the library code.  If I change the
code, then when I do a commit on the library, it just makes a new revision
for those projects.  If I break something, then I can roll back to an
earlier version of the project.