Hi Ian, yes thanks thats helpful, but unfortunately especially in the way that there is no secret cool option (like ctrl-shift-1:)), I'm overlooking. I'm aware that SVN stores only links and that the size only becomes a problem in the local checkout, fact is the original layout was like you describe, but with 500 subprojects I kind of lost it ;). Doesn't tagging take an awful lot of time this way?
Maybe your solution is a lot easier. The downside is like you say, if you pass someone a link to version 1 of project 1 he gets the rest too. Must sleep on this :) Thanks for your time and ideas! Hans On Wed, Dec 10, 2008 at 9:54 PM, Ian Thomas <[EMAIL PROTECTED]> wrote: > Hi Hans, > > Sounds like your problem is really that you're pulling all your tags > from the repository to your local machines (in the repository, they're > just links - on your local machine, they are actual copies). Maybe you > need to reorganise a bit, or make sure your developers only pull out > trunk? > > We have something more like: > > trunk/ > project1/ > project2/ > shared-code/ > build-utils/ > tags/ > project-1-v1-0/ > project1/ > project2/ > shared-code/ > build-utils/ > project-2-v1-0/ > project1/ > project2/ > shared-code/ > build-utils/ > > which isn't ideal (see the unecessary inclusion of project2 inside > project1's tag) but it doesn't cost much in the way of extra space on > the server (since all tags are just logical links, not physical > copies) and means that when we extract project1 at v1-0 we can roll > back our shared code to exactly the right point too. It also means our > build utils are the right versions to recreate that project at v1-0. > > Hope that's helpful! > > Ian > > > On Wed, Dec 10, 2008 at 7:21 PM, Hans Wichman > <[EMAIL PROTECTED]> wrote: > > Hi, > > > > yep using subversion. > > I usually create the tag in my workingcopy, but on the server would be > fine > > as well. > > > > We have one system though with some 500 small projects, all in a single > > repository, which are tagged before they are released. > > But the structure for that repository is like: > > project1\tags > > project1\trunk > > project2\tags > > project2\trunk > > > > Some contentdevelopers have to work on a number of those small projects, > so > > they just check out the root of the repository :). > > Would be nice if you could say something like "get this directory and all > > subdirectories but ignore the tags" or something like that. > > > > Another issue though is that binary assets often completely change after > > updating (eg an flv thats rerendered), so the whole file is submitted to > svn > > again (since about every byte differs). Not sure what I'm looking for > here, > > something like being able to put a file in a repository, without tracking > > it's history I guess (since it's content are derived from other material > > which is leading). > > > > regards, > > JC > > > > On Wed, Dec 10, 2008 at 5:59 PM, Ian Thomas <[EMAIL PROTECTED]> wrote: > > > >> Don't know how you've got your server setup, or which version control > >> system you are using... > >> > >> We are using SVN. If you create a tag, it just creates an alias to the > >> files, not a true copy; so the size in the repository doesn't go up by > >> a huge amount. > >> > >> Are you keeping a local copy of all your tagged code or something? > >> > >> Ian > >> > >> On Wed, Dec 10, 2008 at 2:36 PM, Hans Wichman > >> <[EMAIL PROTECTED]> wrote: > >> > Hi list, > >> > > >> > I was wondering how you handle your assets in version control. > >> > > >> > I usually follow a standard project setup something like: > >> > trunk > >> > branches > >> > tags > >> > > >> > The trunk contains for example sources, deploy, deploy/assets > >> > > >> > Now especially the assets folder tends to get very large. > >> > Each time I tag the trunk, the size multiplies. > >> > > >> > I was wondering how others are handling this, and looking for a better > >> way > >> > to handle the assets. > >> > Not sure if there is a quick solution to this though:) > >> > > >> > regards, > >> > JC > >> _______________________________________________ > >> Flashcoders mailing list > >> [email protected] > >> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > >> > > _______________________________________________ > > Flashcoders mailing list > > [email protected] > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > _______________________________________________ > Flashcoders mailing list > [email protected] > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
