So the concepts of trunks, branches, tags are transparent to SVN. We are in
a situation where we might need to have two trunks in one SVN repository.
The reason is that we have a family of projects - say ProjectA, ProjectB,
ProjectC and so on, each one has it's own repository and have just one trun
On Thu, Sep 9, 2010 at 8:38 PM, Tech Geek wrote:
> So the concepts of trunks, branches, tags are transparent to SVN. We are in
> a situation where we might need to have two trunks in one SVN repository.
> The reason is that we have a family of projects - say ProjectA, ProjectB,
> ProjectC and so
On Thu, Sep 9, 2010 at 8:38 PM, Tech Geek wrote:
So the concepts of trunks, branches, tags are transparent to SVN. We are in a
situation where we might need to have two trunks in one SVN repository. The
reason is that we have a family of projects - say ProjectA, ProjectB, ProjectC
and so on, e
On Thu, Sep 9, 2010 at 8:00 PM, Itamar O wrote:
> On Thu, Sep 9, 2010 at 8:38 PM, Tech Geek wrote:
>
>> So the concepts of trunks, branches, tags are transparent to SVN. We are
>> in a situation where we might need to have two trunks in one SVN repository.
>> The reason is that we have a family
ers"
Sent: Thursday, September 9, 2010 10:38:51 AM
Subject: Two trunks in one repository?
So the concepts of trunks, branches, tags are transparent to SVN. We are in a
situation where we might need to have two trunks in one SVN repository. The
reason is that we have a family of projects - say Pro
svn up
> ProjectD, changes come streaming in.
>
> HTH,
>
> Geoff
>
>
> - Original Message -
> From: "Tech Geek"
> To: "Subversion Users"
> Sent: Thursday, September 9, 2010 10:38:51 AM
> Subject: Two trunks in one repository?
>
>
I am thinking something like this:
ProjectD
ProjectD/PartA/trunk
ProjectD/PartA/tags
ProjectD/PartA/branches
ProjectD/PartB/trunk
ProjectD/PartB/tags
ProjectD/PartB/branches
Beleive me or not in our scenario the code of Part A and Part B never gets
merged at any point. The only common part is tha
On Thu, Sep 9, 2010 at 11:23 PM, Tech Geek wrote:
> I am thinking something like this:
>
> ProjectD
> ProjectD/PartA/trunk
> ProjectD/PartA/tags
> ProjectD/PartA/branches
> ProjectD/PartB/trunk
> ProjectD/PartB/tags
> ProjectD/PartB/branches
>
> Beleive me or not in our scenario the code of Part
Itamar O, yes you are almost there, I have to say very intelligent guess. I
am indeed talking about FPGA development. The only difference is we have a 2
part FPGA on our embedded board. PartA and PartB are both FPGA codes which
are developed separately for their respective chips and then later they
ojectD gets the update at next svn up.
- Original Message -
From: "Tech Geek"
To: "Erik Andersson"
Cc: "Geoff Hoffman" , users@subversion.apache.org
Sent: Thursday, September 9, 2010 1:23:27 PM
Subject: Re: Two trunks in one repository?
I am thinking somethin
Geoff,
I think I am beginning to undestand what you are suggesting.
Right now I am in process of implementing this setup. At this point nothing
exits - no ProjectD, no PartA and no PartB. So I will try to summarize what
I have undestood so far:
1. All our SVN repositories lives under the followi
On Fri, Sep 10, 2010 at 12:36 AM, Tech Geek wrote:
> Geoff,
>
> I think I am beginning to undestand what you are suggesting.
>
> Right now I am in process of implementing this setup. At this point nothing
> exits - no ProjectD, no PartA and no PartB. So I will try to summarize what
> I have undes
oject admin's decision.
Ben
- Original Message
> From: Geoff Hoffman
> To: users@subversion.apache.org
> Sent: Thu, September 9, 2010 5:12:52 PM
> Subject: Re: Two trunks in one repository?
>
> SVN won't care, but our IDE may not like it like that. The only rea
>In SVN a working copy does not include the revision history, which remains
on the server (as opposed to Git or Hg).
Yes. I am aware of that.
> In order to see a revision graph (TortoiseSVN feature), you need to
communicate with the repository.
Yes. True.
>In fact, you don't even need a working c
For some reasons this message was returned to me by the mailer daemon. So
resending it again.
>In SVN a working copy does not include the revision history, which remains
on the server (as opposed to Git or Hg).
Yes. I am aware of that.
> In order to see a revision graph (TortoiseSVN feature), you
15 matches
Mail list logo
